Requirements Defined - Seilevel's Software Requirements Blog

Resource with Tips for Virtual Teams

noreply@blogger.com (Joy) — Mon, 02 Nov 2009 15:00:00 +0000

I am a huge fan of Thiagi's work on games to use in training. He has made many games publicly available for use in your own training environments. In the past I've done some writing (here) about how we've adapted his games to Requirements Engineering training courses. But today I was browsing his site and found something I thought might be useful to others. He has posted a list of tips for virtual teams. There are just over 100 simple tips, that if you just skim the list I'm sure you'll find a handful of them can be applied immediately in your organization.

Does anyone have comments on ones you will start to use or additional tips to add?

Delivering Business Value with Agile Approaches to Requirements, continued

noreply@blogger.com (Joy) — Fri, 30 Oct 2009 14:00:00 +0000

This post is a continuation of a previous post found here.

Changes Dave believes are coming with respect to agile-run projects and my own commentary on these:

Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.

BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.

Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.

The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.

The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.

Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.

And finally, Dave made my favorite quote from RE’09: The difference between UML 1 and UML 3 is that we moved the stick hands from being straight out to angled downwards. He can make jokes like this since he actually worked on it!

Delivering Business Value with Agile Approaches to Requirements

noreply@blogger.com (Joy) — Wed, 28 Oct 2009 14:00:00 +0000

I attended a keynote at RE’09 in Atlanta that I wanted to go back and post a summary of and my thoughts on. And just to be completely honest, this is a rarity. For whatever reason, I really tend not to get much value out of keynote talks – either they are too technical, the speaker isn’t great at well, speaking, or they are so out there I cannot engage in it. Today was different though, it was captivating for me. This one was given by Dave West of Forrester Research. The talk was titled “Developing Business Value with Agile Approaches to Requirements”.

To be fair, he had my attention at the first slide – it was a picture of a dog doing agility. When I talk about agile, I use such a picture too since I personally do agility with my dog! Anyway, the content of the talk proved to be interesting. Some will say it wasn’t anything new. Others will argue with what he said. But for me, his ideas were very tightly aligned with our experiences and ideas about agile and requirements so I like that it built on what I already knew and gave me new ideas to think about. The great thing is he has a much larger pool of resources to survey and confirm his ideas. Here are a few of the points of interest.

He talked to what is being adopted with respect to agile and among those things: Agile itself is being adopted. Scrum practices are as well. He also sees engineering practices such as early testing, integrated builds, and re-factoring. But most of note, he is most commonly seeing a hybrid of approaches– more of an agile than an Agile approach. I think this is relevant as I hear company after company say “agile didn’t work for us”. In reality for many companies it probably doesn’t in its purest of form. Or perhaps it requires trying it more than once, learning from mistakes (do we really think Waterfall worked the first time either?!?!).

Some really positive things he believes we are seeing now include frequent delivery, increased business involvement with more collaboration, and changes in team organization towards smaller teams and more of a team focus in general. His thought on when agile is best used: Complex projects where there are problems to be solved and the solution is unknown.

Dave spoke to the common friction points between traditional requirements approaches and agile:

Delivers requirements vs collaboration on the product
Where in the process you engage vs. iterative
Requirements that are out of date, long/hard to read, solution focused, take way too long vs. collaborative and timely requirements

Some of the issues that you must be careful about with agile: Often the customer has no time because they are doing their day-job (the one you are trying to help in some way with software!). There are often many customers to involve in the requirements efforts, not just one or two to quickly jot down stories with. The customers are often distributed so you have to bake in time to work with all of them alone and together. Agile is reliant on good communication but stereotypically, developers don’t communicate well. We cannot ignore analysis - processes require analysis and solutions require thought - so take time to do these.

I will continue this post in a day or so with thoughts on changes that Dave thinks we are starting to see, as well as my personal thoughts on his thoughts!

An example of Blueprint in Use on an Agile Project

noreply@blogger.com (Joy) — Mon, 26 Oct 2009 14:00:00 +0000

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

BluePrint Tool

noreply@blogger.com (Joy) — Fri, 23 Oct 2009 14:00:00 +0000

I attended a talk by folks from BluePrint and LexisNexis at BAWorld on Tuesday. The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from someone who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and BluePrint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for BluePrint, but it was given by an actual user....and you could tell she was being honest about it.

BluePrint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

I haven't used BluePrint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Creating BA Competency

noreply@blogger.com (Joy) — Thu, 22 Oct 2009 14:00:00 +0000

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Using Use Cases To Create Test Cases

noreply@blogger.com (Joy) — Wed, 21 Oct 2009 15:00:00 +0000

As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".

His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.

This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.

If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.

Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
Use your BAs during UAT - particularly for the less important test cases that the users can't it.

BAs Need to Think Quietly

noreply@blogger.com (Joy) — Tue, 20 Oct 2009 00:22:00 +0000

Also at BAWorld: Boston, Monday I heard Barbara Carkenoard talk about "ROI? Measuring the Real Value of Business Analysis" and her learning objectives were:

Learn to talk about the specific value of a strong business analysis discipline
Consider business analysis metrics for use in your organization
Understand why a financial ROI is not normally calculated for business analysis

Some of the key points of interest for me were these, with my own commentary:

Business analysts should be involved in creating the business case. Most projects don't bring them in until the project is already decided upon. But business analysts inherently are good at analysis and can really think through whether a project even makes sense.

Business analysts need to figure out how to block out big chunks of time to think quietly. Analysis requires thinking...so let them think!

An interesting discussion took place around cultural differences between countries and how it relates to the use of process or lack of. This came out of a question about why organizations try to short-cut business analysis on the projects. And Barbara proposed that the US culture is one of "hurry up, slam it in, we'll fix it later" whereas a lot of other countries (she named Canada and the UK) are more likely to follow a process to get it done right. I laughed because just last week I had an executive say "It's okay if we don't get all the requirements defined, we'll just log everything not yet written down as defects and fix them in QA"...and he was very serious about it.

Live from BAWorld Boston

noreply@blogger.com (Joy) — Mon, 19 Oct 2009 22:53:00 +0000

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:

Understand how Business Objectives are vital to businesses
Understand how to elicit and write good Business Objectives
Understand how to use Business Objectives to assess measurable value of individual features

I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Requirements Soundtrack

noreply@blogger.com (Joshua) — Fri, 09 Oct 2009 14:00:00 +0000

I am going to take it a little off the beaten path for this post and ask about some 'non-functional' work requirements you have. So I was wondering what you all like to do when you have to stay focused? Do you listen to classical? Work remotely from a coffee shop or home? Put a big frown face on your office whiteboard warning intruders to stay away?

I personally have my ear buds on hand wherever I go to work. They help me whenever I need to keep my head down and not be distracted. Granted, the slow and methodical opening of 20 or so metal blinds with 5 or 6 pulls each isn't easily drown out.

I favor listening to either Classical or Spanish Guitar music for working at the client site or office. Not for the 'classical makes your baby smart' argument. I do find that these two types of music help instill a calm demeanor and have enough movement in the music to help you get into a pattern. The ear buds themselves do the work of drowning out the background conversations regarding the explosion of a stress ball and its contents upon the ceiling.

Alternatively. When I have a large quantity of documents to review or large processes/maps to create, I favor my home office. I can't help but need a great chair, huge monitor, and fast internet for researching in these cases. Granted my music changes to more modern content to keep the mind from burning out on the same tasks. But in either case, I welcome some interruption since I am not the only one with deadlines.

Do you have different styles of work when it is focus time? Let us know, we would love to hear back from you. Perhaps you had a moment that you really wished you had some way to stay focused.

12 Things to Fertilize Your Business Analysis Career - Addendum

noreply@blogger.com (Joshua) — Thu, 24 Sep 2009 14:00:00 +0000

Jacqueline Sanders wrote a wonderful article that was posted on the modern analyst site, I highly recommend you read it. In it she writes briefly on the background of the Business Analyst field and several pointers for becoming a better and therefore more distinguished Business Analyst.

I have a few suggestions for some of her points.

1. Associate with Other Professional BA's. Great point. This should extend to networking in general with a focus on BA organizations and individuals. There are numerous organizations that host local networking events and seminars. They don't have to be regarding product managing or business analysis. Door64 and Austin Tech HH offer many events where you can socialize with the people you will be interfacing with the most in your job, not other BA's, but developers, SME's, and managers. More importantly, while it is good to be part of the in crowd of BA's, if you are trying to land a job or help secure a deal, you've got to know the people with the projects.

2. Seek the Body of Knowledge (BOK) / Become Certifiable / Talk Like a B.A. Learn up on your BABOK, get certified where applicable, and know the language. Its challenging enough to translate business speak to functional requirements, no need to toss in BA's with different communications. There is no substitute for BABOK and certifications. However, it is not enough to talk like a BA. I highly recommend subscribing to news feeds / blogs / articles to get all the recent traffic and best practices. Don't just do this for business analysis based information, get into feeds for the space you are working in as well as development information. When you start talking like a BA and someone else starts talking like a developer, you should be able to quickly translate and ensure the same page was landed on.

3. Tools of The Trade. As Jacqueline says, MS Word, Excel, and Visio are not enough. I can almost guarantee you that SharePoint will be involved. You should get to know and love this tool (unless you are provided with another one, in which case you probably shouldn't mention SharePoint). It will be imperative to use the shared task, communication, and document capabilities of this tool. As for getting to know other tools, if you have the free time, go out there and look up requirements management software and get a hold of all the free trials you can. Get to know any of the lists that inform you about which software offers what values.

4. It's Hard to be Soft. Just like you would carry around a portfolio of your accomplishments, try to keep in mind your experiences that played out based on your soft skills. Jacqueline states it perfectly," hard skills will get an applicant an interview, but soft skills will get that person a job." Be ready to tell an interviewer how you were able to reject the project sponsor's features without causing a political debacle and making sure they were alright with the decision based on the business needs. These experiences are just as important as your 14+ years of Visio usage.

5. Know You are Not. Jacqueline points out that we Business Analysts are not people who satisfy simple tasks. That we are not just a middle man in getting the information from the fax machine and giving it to the engineers as one lovely movie puts it. We are devoted, business-minded professionals. Everything we do should be an ROI based thought process because that is what we do. If someone doesn't understand your role, it might even be hard for you to describe. I make sure sound business decisions are executed. I make sure that products meet project needs. I ensure that business needs are met with new or changing processes. I write high level, common and excruciatingly detailed documents. I am the facilitator of meetings to make sure we didn't waste the entire leaderships day of work. I am the discoverer of everything everyone else forgot to mention. At this rate, I may also be Spartacus.

Our role is diverse and requires dedication to execute well. I find it funny how I never knew this type of job existed growing up, if you recall the silly aptitude tests growing up. I would like to reiterate that this is just a list of some of my personal thoughts regarding some of Jacqueline's points. Please go read her article. Is there anything you feel we are missing out on?

What's My Name Again?

noreply@blogger.com (Joshua) — Tue, 22 Sep 2009 14:00:00 +0000

Monthly Sales Revenue Generation... no

Monthly Sales Group Rev Production... no

Sales Revenue Performance by Month... no

Sales Revenue by Month for Overview... maybe... yes, that one was it.

Speaking from experience, trying to document vital business information when it all is named with generic operational mumbo-jumbo will slowly cause your brain cells to rebel against you throughout the day. If you haven't given in to their demands by the end of the day, your brain could retaliate by making you forget vital information like your name, favorite color, or the air speed velocity of an unladen swallow.

Concerns for your own health aside, the business is put at risk when vital documents or business processes are not identified correctly. Loss of documentation can lead to costs for replacing it, failed process attempts, legal actions, and bad requirements for projects.

To prevent that from occurring, a system to easily identify information correctly is needed. In the strictest form, the information you are working with should have unique ID's (not like the ones at the beginning of the post though). If you use requirements management tool like Caliber, then your entries should be given unique IDs. If not you will have to come up with some system yourself.

A combination of letters and numbers work well to prevent ID overlap. I tend to favor a 2 to 3 letter prefix that is some sort of abbreviation for the information such as 'RO' for report object or 'IPD' for InfoPath Document. This will help add much needed meaning to an identifier without having so many words to say so in the first place. It also serves as a code that is easier for machine side recognition if applicable to your project.

Now we have our lovely hybrid id. What do we name our document? Some people like to use summaries (which unfortunately, in my opinion, are informative mostly based on how you see things.) I try to use a generic name that describes the overall purpose of the doc such as 'Sales Dashboard' or 'Customer Credit Registration'. Those types of names will most likely be commonly accompanied with dates relevant to the creation of the document. Try to append the date in a manner that is friendly to alphabetical sorts (i.e. 2009-08-26).

Now the part that some of us will not like (I am looking in your general direction agile extremists), write down in a list that all these documents exist. Descriptions, owners, and change management rules for these documents will prove invaluable later. While other BA's are telling stories about how this one employee quit 4 years ago and the sales process is relying on a SQL database running off of an old laptop that person setup which they are now trying to bypass, you will be quickly identifying which documents need to be migrated to the new system and being confident you got all the relevant organization's buy-in.

Live from RE'09: New Ideas for Requirements Activities in Distributed Teams

noreply@blogger.com (Joy) — Wed, 09 Sep 2009 15:00:00 +0000

Olly Gotel from Pace University presented work she has done with colleagues from around the world in a paper titled Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill. Olly started this talk by telling us that she had done something crazy with this project, and then went on to explain how they had essentially five different teams working on a project from five locations around the world. They were each supposed to write requirements for a software development competition, with requirements teaching and coaching help along the way from professors and experienced students. As she went on to describe the experience, many of us from industry chuckled with her out of empathy – her experience is so similar to our worlds today where the teams are distributed worldwide and chaos ensues!

There are a couple concepts from Olly’s course design that I think would be great to replicate in industry – either from a training perspective or project execution. The first one is related to creating competition to improve results. In past iterations of this learning experience, Olly explained they had issues with the students not understanding the value of producing quality requirements, which naturally resulted in poor results. So this time they had the teams compete with one another by creating the same deliverables and having the client choose which solution was best. As expected, the competition significantly increased the quality of their work products. We have done this with our training courses – introduced friendly competition through game playing and I’ve been pleased with the level of engagement. However I think there is something interesting to think about here with respect to injecting a different type of friendly competition into project execution in industry. Fundamentally the big turn-off to this idea in industry is that there are five times the costs to create the single project – so it's a lot of throw-away work. But, if we think outside the box a bit, perhaps we can divide projects into chunks (or just use multiple projects) and have the requirements sub-teams compete on quality of specifications, requirements issue resolution speeds, project success rates, etc.

In this course, they used an apprentice model with coaches who were students that had previously completed the requirements engineering classes. Now I think this is something that absolutely applies as-is! You can just have mentors who are more experienced people mentoring the more junior resources in requirements activities – ideally pairing them up on the same projects.

Live from RE’09: Taking Distance Requirements Training to a New Level

noreply@blogger.com (Joy) — Fri, 04 Sep 2009 17:51:00 +0000

Didar Zowghi gave one of the most interesting talks at REET'09 I’ve heard in awhile titled Teaching Requirements Engineering to the Baha’I Students in Iran Who Are Denied of Higher Education. She was asked to teach a distance learning course on requirements engineering to these students from Australia to Iran.

She basically runs the course by teaching lectures using audio and displaying the lecture slides using Skype or LiveMeeting. However, they ran into issues with everything from bad audio connections, students who couldn’t see the visual slides, and even power outages. One improvement made eventually was to record her lectures so students could download them to play if they couldn’t hear for some reason during the live presentation. As a bonus, Didar said she learned of things she could work on by listening to herself lecture for the first time!

She had assignments for the students as well, but specifically she had a project where they had to interview a stakeholder to elicit and document requirements. She had a Teaching Assistant located in Iran who played the role of stakeholder – sometimes in person, sometimes by phone. She had the students use Karl Wieger’s templates since those were also easily downloadable.

Didar also makes time to chat with students – they might Skype her for example to find a time to chat verbally. I like to think of these as virtual office hours!

I found Didar’s talk to be so interesting based on the circumstances behind it – a great culture lesson that I thank her for. But I also find it quite relevant as we work to roll out global training programs. I am sometimes overwhelmed by the idea of how we will possibly have successful training with people on the other side of the world, but the reality is – you just make it work.

Live from RE'09: Contextual Requirements Experiences within the Software Enterprise

noreply@blogger.com (Joy) — Thu, 03 Sep 2009 18:48:00 +0000

Kevin Gary from Arizona State University presented Contextual Requirements within the Software Enterprise at REET’09. He discussed their approach in having a multi-year project-based engineering course sequence, allowing for iterative exposure to all concepts - but particularly of interest: requirements engineering. This very much fits with popular learning theory – the idea we need to put concepts in front of students repetitively for them to really learn them. For their projects, they reach out to industry to find candidate projects so the students get to work with real subject experts to solve real problems, ultimately producing real deliverables. What I like about his style is that he is less interested in whether the company gets their perfect solution out of this work and instead he is more interested in whether the student is learning the concepts. But in reality, it sounds like the companies are getting a lot of value out of it!

One of the challenges Kevin spoke to involves how you assess students in courses like these. One thing I do like that I haven’t seen often is that he tries to check in with industry managers that hire his students to see if they are coming out of the ASU program more prepared.

So what I like about Kevin’s discussion first of all is that assessment of students is hard! We see that too and it was a big topic in an REET panel later in the week at RE’09. But I really think it’s great to see universities with programs really aimed at setting the students up for success in industry after graduation. And the final point I’ll make is that he’s absolutely right about needing students to practice the lessons lectured and hear them more than once. I think this is a major flaw in much of the requirements training offered to industry right now. We send students in for a class and then expect them to get it all - typically without revisiting the materials again.

REET’09 Went Off Without a Hitch!

noreply@blogger.com (Joy) — Wed, 02 Sep 2009 03:59:00 +0000

Monday was the Requirements Engineering Education and Training (REET) workshop that I co-chaired with Ljerka Beus-Dukic. I’m always nervous about how these things will go – there are so many unknowns with the environment, the presentations, and the timing. However, I’m absolutely thrilled with the end result! We had 6 papers presented and it varies from a normal conference in that we had big blocks of discussion to really dive into some of the commonly shared issues in this field.

We had a lengthy discussion mid-afternoon around how do you really teach anything about requirements to students in a semester long class (or less!) and where does requirements training fit in the overall teaching of the software lifecycle at a university level. The thought is that most people learning about requirements in industry aren’t brand new to software development, they already understand a bit about coding and verification, so they understand the value and context for requirements. Yet trying to teach it to a freshman class would leave the students thinking “why do I need to know this?”

Another key point that is important at all levels is repetition in the lessons they receive. It came up again in the context of academia, where they may teach it to freshmen, and then they need to re-teach it throughout in other classes. This isn’t specific to requirements certainly, just a basic principle of good training.

We also talked quite a bit about how you assess the students in and after training. This is a long standing BIG problem across academia and industry. One issue with assessing whether any behaviors changed in an academic environment is that you teach it and they may use it on a project, but then you never see the students again. One participant actually tries to talk to industry contacts who hire the students to see if they see better results from his students. In industry, it’s very hard to isolate whether results are attributed to training. We can look for modified behavior, but this requires a dedicated resource to do so. I’ll probably talk about this more in a day or so, since we have a panel related to this on Thursday!

We then ended the day with 3 different sets of training activities presented with the intent on getting any participant feedback on the activities, but also leaving the workshop participants with the opportunity to take the exercises back and reuse them. At the very end, we played one of our Seilevel training games: Bet on Yourself Pictionary – it was fun because I was working with a group of people who are already familiar with requirements models in some form and so they could play our game – which basically enlists 2 “students” to act as analysts drawing requirements models for a specified scenario, trying to get the rest of the class to elicit the requirements from them. Oh and they had to do all of this without speaking. It was great fun and if nothing else, a lively way to end the day!

Live postings from RE'09 next week!

noreply@blogger.com (Joy) — Fri, 28 Aug 2009 14:00:00 +0000

It's one of my favorite times of year, time for the IEEE Requirements Engineering conference! RE'09 is just around the corner, starting next week in Atlanta, GA.

I'll be co-charining the Requirements Engineering Education and Training (REET'09) workshop on Monday and then attending the main conference the rest of the week, with 2 panel appearances that should prove to be interesting.

And as always, I'll be blogging LIVE from RE'09! I hope to see some of you there, find me if you are attending this year!

RML™ Requirements Model 6 - The Business Data Diagram (BDD)

noreply@blogger.com (Joshua) — Thu, 27 Aug 2009 14:00:00 +0000

Even if you don't know what it is called, we have all used one of these or something similar to it. You know, the last time you were playing the timed, trivia, board game. If Bob is Joe's uncle, Jessica is Bob's cousin, Paul is Jessica's father, and Joe is Paul's grandfather, what is Paul to Joe? Then you team stares blankly for a few seconds while someone scrambles for a pencil to start charting it out. Chances are you drew a BDD to figure out how those people were related (however poorly drawn the diagram was).

A Business Data Diagram is an essential component of the RML™ tool set. The BDD shows the relationships between entities included in a project, and the cardinalities between these entities. This diagram will look very similar to an Entity Relationship Diagram (ERD) if you are familiar with those, however it is a conceptual data model only, in other words – a BDD does not represent a physical data model (or even the fact that there is a database). We use this name as to not confuse anyone that may be familiar with ERDs, falsely implying a database design. Example included:

Why should you want to use the BDD? Because its fun to play connect the data objects, or more practically, when you have other data models. When you have other models, this is a good way to show the relationships of the data objects. Creating this with the other models also helps you make sure you aren't missing data objects. Be sure to take note of all the 1's and n's in the diagram. These are there to help you understand many-to-many/many-to-one-/one-to-one relationship types. In the example above, it is saying that each customer can have many orders associated, but each order can only relate to one customer.

Be careful to not add fields and other specific details regarding the data. This is not a database schema . That would be designing the system and we don't want to do that. That being said, a database admin could use this diagram to understand the relationships that will need to be supported in the database. If the requirements are not related to this presentation of information, it might be a good idea to skip this diagram.

Once you create this model, for each data object, you can then look at how each object is created, read, updated, deleted, copied, and moved within the system. This will help you identify additional systems that may be involved and use cases to be described. I commonly add these types of diagrams at the start of a high level view of a set of functionality so that the reader can get an idea for the data interactions before they get to the use cases, test cases, etc. that make up the meaningful requirement information.

Mission Elicitation - Phone Meetings

noreply@blogger.com (Joshua) — Tue, 25 Aug 2009 14:00:00 +0000

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

ProductCamp Austin is this weekend!

noreply@blogger.com (Joy) — Wed, 12 Aug 2009 03:04:00 +0000

ProductCamp Austin is just around the corner! It's this Saturday from 9am-3:30pm. I unfortunately am out of town yet again for it, but Tony Chen will be representing Seilevel at it this summer. Hope to hear great stories back from everyone attending!

Project Pulse - Project Velocity

noreply@blogger.com (Joshua) — Tue, 11 Aug 2009 14:00:00 +0000

Or we could call it 'Project Speed' if you are a big fan of movies where objects that move too slow are reprimanded with high explosives. Either way, we are talking about a project management metric that is very helpful in identifying problems and adjusting milestones.

What you will need:

o A Project

o A team or yourself

o A task list

o Estimated hours

o A record keeping system (such as excel or crayons and paper)

What you will be doing to monitor a project's or individual's velocity is assigning an estimated task time to all the new tasks that may show up on your project. So first make sure that you have a list of all your known tasks and that you and/or your team has given a best estimate for time to complete them. Once this is done, go ahead and add up the total estimated hours and set that aside. For now, lets say that you came up with 100 hours of tasks.

Go ahead and work on the project for the day. Either at the end of the day or before working the next day, get the sum of project hours remaining and record that again. Lets say that the first five days yielded 104, 115, 103, 93, and 80 with two people working on the project.

In the perfect world you would assume that two people working a project would net you 16 task hours completed a day. As we all know, this will not happen or we would all be spending additional hours at work for meetings, side tasks, waiting for feedback, dealing with IT issues, delegating work, etcetera just to get the 8 hours of task work completed (wait a minute...) So, now that we have the remaining estimated work for the week, we can figure out the velocity daily or the average. Starting with the daily, the team seemed to have the following results; -4, -11, 12, 10, 13. Taking the average of those hours will give you 2 hours/day as your current 5 day velocity.

What does it mean though? This is where you will have to take a closer look at the data or have a meeting with the team. In this particular case, we gained hours on the project time during the first two days. After that we seemed to get what could be considered normal results. Possible causes of the velocity could be from any of the following: incorrectly estimated task hours, discovery of new tasks during project ramp up, poorly performing team, obstacles are preventing task work from being completed, failure to properly update tasks with remaining hours, or shared resources being used on the project. Some of those same reasons could also be the cause of a faster than expected project velocity. Alternatively, unique causes of a faster velocity could include the rapid closing of tasks toward the end of a project when estimations are not as conservative, resources performing above expectations or putting in additional time, or removal of tasks from scope.

Once you understand why your Project Velocity is what it is, you can now reforecast when your project milestones will occur based on the current performance. It will also help you identify if any of the issues mentioned in the prior paragraph are occurring so that you can fix them or congratulate the team for the good work. Keep in mind that you should see slower rates at the start of a project, where new tasks are being discovered and people are being conservative about how much time is required to complete tasks. Faster rates should occur towards the end of the project where tasks are being knocked out of scope or finished with better efficiency.

Try using this data for a project dashboard that shows current data, historical trends, and project goals! Bonus points if you work in a speeding bus!

Why meetings are so disruptive

noreply@blogger.com (Anthony C.) — Thu, 06 Aug 2009 14:00:00 +0000

Paul Graham has a great article on his blog on why meetings feel so disruptive to many of us. He partitions the world into managers and makers. Managers live their working life in 1 hour increments, so slotting a sudden meeting in is no big deal. It is just an issue of where to go. Makers live their lives in at least half day increments so that a one hour meeting can render half a day completely useless. When the two worlds collide, the makers suffer.

As Product Managers and Business analysts we have to be both. We have to have a lot of meetings where we make decisions and try to figure out what the project is going to be. Then we have to have quiet time to create the specifications. It is really difficult to switch back and forth and he offers several strategies for dealing with the context switching.

Paul mentions that a very common strategy is for makers to just ignore meeting requests. I definitely have used this strategy many times, but it is a little rude and can obviously be a bit offensive. These days I tend to put all my meetings first thing in the morning or towards the end of the day. This lets me focus on productive work with a block straight through the day. The difficulty comes with people always wanting to go out to lunch. When my productive block is from 10am to 3pm, having lunch is actually quite disruptive.

How do you handle the maker vs. manager conflict?

A Better Way to Write a Use Case: Plain English

noreply@blogger.com (Joy) — Tue, 04 Aug 2009 14:00:00 +0000

I was talking to a colleague recently about use cases and it got me thinking about my evolution as a use-case-writer. I used to do formal use cases exclusively – where they very clearly denoted system and user steps (whether in one list or 2 columns), preconditions, triggers, Postconditions, etc. etc. etc.

After years of writing and teaching about formal use cases, I have to confess, I rarely write them now. Sometimes I still teach about them, I think it’s important to know how to write good ones. But the reality is that as we move towards shorter-iterations on our projects, the less formal we need them to be in the use case itself. What I’m finding works really well are these use cases written more like user stories. They may still have a linear set of steps, but the big difference is they are written in a more readable language of plain English with slightly less structure.

I’m oversimplifying but to make my point, instead of:

1. System displays shipping fields

2. User enters shipping info

3. System displays payment options

4. User enters payment options

I could simply say:

User enters shipping and then enters payment information.

I’ve conveyed the same information without stating the literally obvious points. You have to be careful here though, don’t assume the obvious incorrectly! Now, before you agile non-documenters jump up and down and say “I told you so!”, I want to be clear – you still need to write something down. This is the part that many projects neglect to tackle is the next level of detail. You still need to capture specific functional requirements for this use case/user story – there are our typical RML™ – with people, systems, data models to be created that describe those requirements, So I use the user stories, just like I used a formal use case – stepping through each “step” and determining what details need to be specified for building the software. Oh and one more thing, I do still use preconditions, triggers, and actors in the header – just makes it cleaner to call those out up top.

Just a reminder - you never know who's going to walk through the door

noreply@blogger.com (Joy) — Wed, 29 Jul 2009 14:00:00 +0000

We had what I like to think of as a "consulting skills 101" moment as a nice reminder to “Be nice to everyone at your customer site…you never know who is about to walk through the door.”

We were in a meeting room waiting on our stakeholder. Two guys walk in saying they thought they had the room reserved. I told them I had received an acceptance on the reservation, but also offered to leave if they needed it (as we were only 3 people, and I was thinking they might have more attending theirs). They offered they would rather go find another room with a better projector. The point is I really was just trying to be polite to these complete strangers….and they weren’t being pushy, but if they had, I’d have let them have the room without hesitation.

So about 2 minutes later our stakeholder shows up and we start our meeting.

Another minute or so later…a man opens the door and walks in. He stops in his tracks when he sees us, and announces quite firmly “I have the wrong room!”. I got over my urge to cringe and instead just let him know they had gone to find another room. He smiled and left.

Why did I cringe you ask? Because he was the CEO of an F500 company. And now our project team jokingly asks me when I schedule rooms if I'm kicking the CEO out for that meeting too.

Anyway, what I will say is that none of them missed a beat - they could have played the hierarchy card on us at any point and they didn't. A sign of great character!

Project Pulse - Constraint Tracker

noreply@blogger.com (Joshua) — Mon, 27 Jul 2009 14:00:00 +0000

I was just wrapping up a project co-writing a 90 page requirements document for a client and I am so proud of my work! Unfortunately our statement of work with the client says that we would only document at most 45 pages estimated at 3 pages per requirement. With this data in hand we were able to approach the client about this potential budget buster. We were both able to come away from the situation happy due to extended budgets and robust requirements. What if this happens to you? What if you aren’t working on a project that has the luxury of flexible resources? Are you prepared to protect it from hitting that brick wall?

You probably need some sort of daily gauge letting you know where your project is in relation to your constraints. Some common project constraints are pages of documentation, number of requirements, hours, or budget. Try to keep track of these stats daily to maintain a dashboard both for yourself and for the stakeholders on your project.

It could look something like this:

These graphs will provide you with a quick easy to understand overview of where you are with your project constraints. With this understanding, you can better direct your work or your teams and when needed, go to your stakeholders and tell them that they may not get what they wanted with evidence why. It could motivate them to provide you with the additional resources you need to get the project completed right!