After the SRS

You've just finished a two-month, 150+ page SRS, gone through the validation process, and have sign-off from everyone. Congratulations! Time to kick back, relax, and watch the other teams build the product, right? Well, not exactly. As Product Managers, we still have a responsibility to help ensure that the product is completed correctly. In this post, I'll discuss a few roles and activities that we play after the requirements are completed. Whether you as a Product Manager play these roles or not will depend on your organization and project - however, it is important to understand that all of these roles are necessary and they need to be completed by someone, whether a Product Manager, a Project Manager, or someone else.

First and foremost - requirements change. Business priorities shift, additional information is uncovered, and interaction between design and requirements all necessitate changes to requirements. A comprehensive change control process is a must for any project. Dan recently wrote a post suggesting a change control process. Usually the Product Manager is a key player in the change control process, if not the person running the process.

Acting as an interface between the business and the development teams is another key role to play post-SRS. No matter how well written your documentation is, designers, developers, and testers will have questions. Their questions may require you to go back to the business for clarification. You will also need to review development artifacts such as design documents, prototypes, completed development, etc... Depending on how the project is structured you may need to coordinate between business stakeholders and the IT teams to facilitate review and feedback.

While the testing team has primary responsibility for verification, Product Managers play an important role as well, particularly during user acceptance testing (UAT). Typically, the business does not have all of the required skills to setup UAT, write test cases, and execute testing. Product Managers can play a very helpful role in assisting the business with their testing responsibilities (e.g. leveraging use cases to produce UAT scripts).

Product Managers should assist in the verification of training and user documentation. In fact, depending on your organization, you may be the person producing training and user documentation.

The next two roles will really depend on your organization - a lot of larger organizations have specific teams or individuals separate from Product Management who have these responsibilities. The first is rollout, and the Product Manager may be involved in helping to plan how roll-out will occur, when certain groups will get the new application, how training will fit into rollout, and other activities. The second responsibility is on-going support and maintenance, which could involve tasks like providing initial user support, training a support desk/group, and doing triage on in-coming defect reports and change requests.

Last, but not least, requirements work is a process - and with any process you should examine the process for potential improvements. After you are done with the SRS, you should take the opportunity to see what went well and what didn't. You should also take this opportunity after the project to re-examine what could be improved in the requirements process.

Organizing Information – Part 2

Assuming you have a basic target format for your requirements (a template or structure in a tool), you need to decide how you are categorizing the information within that format. For example, you might be grouping requirements by feature, by use case, by sub-system, etc. In Part 1, I discussed an approach for this, to organize information that feels like complete chaos.

Now, let’s say you now have contained your chaos to a document (more or less). This most commonly looks like one or two sets of notes that just need to be massaged into true requirements. The following steps outline an approach to handle turning your notes into requirements. For the moment, I’m going to assume we are moving requirements to a template before moving importing them to a tool.

1. Categorize the information in your notes

First, you need to step through your notes, putting each of the pieces into the appropriate section of the document based on your categorization of information. This works for input sources other than just your notes also.

You have a couple choices here about how you get the information into the final format. If you are moving to a template, you can either put your notes in the template and work on them inside it, or you can move the notes into the template, working on them as you insert them.

If you are working in the document, you can cut and paste the content blocks to move them around in a logical fashion. Delete any obviously extraneous information at this point.

If you are moving content to a new document, then use a virtual highlighter to highlight things that have been moved into the actual document in one color, and use a different color to indicate things that you’ve decided not to use.

In all cases, be sure to save your raw notes off before you start this process, so you can get them back later if needed.

2. Log open issues

As you process the notes, put any open issues into the issue tracking system for further tracking.

3. Revisit the categories again

Take a step back to review your categories within the document for overall completeness. You should be able to apply some high-level models to do this. For example, you could use a high-level process flow to validate you have all process areas represented. You might use a system context diagram to validate you have all components covered. In general, verify that you have covered people, systems and data models. If you use models to validate the high-level categorization, you should typically include those in the overall requirements.

4. Complete known models

Since your document is physically grouped now, you can work within each content block to address the completeness. Again, you will use models to complete the content. Complete diagrams that were started in your notes. For example, often in a requirements session you will draft a process flow. This is the time to clean up the process flow diagram, including appropriate branching. If you drafted use cases in a requirements session, you would now formalize those to the degree necessary.

5. Create individual requirements

You probably have a lot of text from your notes. You should take a pass through the word content to separate out individual sentences as requirements. Each line should be just one requirement when you complete this.

6. Clean up the requirements

Take a pass on the individual requirements to formalize them, including adding IDs to requirements. Make sure they are each individually written well – good English, sensible, clear, etc. Remove duplicate requirements.

7. Find the gaps

This is the hard part – find and insert missing requirements – easier said than done. You will likely need to apply new models, using the requirements that you do have. For example, you might realize in your notes you have a list of system states and descriptions. This would prompt you to create a state table so that you can identify the transitions and missing states. While this post will not go into the use of models, we have many other posts on the blog that you can search and read about this.

Finally, if you are working with a requirements management tool and want to put your notes directly into the tool, this is more complicated because you have to simultaneously analyze, process and move - for each piece of content. I would encourage you to apply some of these techniques in your notes before you start putting them in the tool. But for example, you can do steps 5 and 6 while you move the individual requirements to the tool.

How did I miss that?

A few weeks ago, I was participating in a design review session for my current project. The visual designer was walking the project team through his UI mockups for a particular feature of the system. He asked us a question to clarify the functionality of one of the UI "widgets," which the business SME/sponsor answered, "It should [do X]."

Her answer didn't quite match up with the requirements she had recently approved, so I spoke up. "Well, that's not quite how you said it should work," I interjected. The group looked in my direction. "The requirements you just approved said that the system would allow the user to [do Y], but not [do X]. Is that not correct?" I asked.

Her reaction was a loud "How did I miss that?!?". My reaction was "How did I miss that?!?". We each couldn't believe that we hadn't seen the error (her miss) or seen the possible contradiction and asked a clarifying question (my miss). Our shared reaction got me thinking ... how can we make sure that we don't miss things in the requirements process?

And then I realized that that was the wrong question. We'll always miss something the first time around. Project schedules are short, the work is intense, and we're human. Something almost always slips through the crack, in spite of our efforts to the contrary. So the important question isn't how to prevent missed requirements (although we should structure our work to prevent those misses when possible), but how to catch them as part of the overall requirements process.

Requirements review and approval cycles are a great way to catch missed requirements, particularly if you have reviewers who haven't been deeply involved in the elicitation of the requirements. A fresh set of eyes always help spot the missing details. Peer reviews work well, too, since fellow Requirements Engineers know what to look for in a good set of requirements. Design sessions and walkthroughs can also be helpful, as was the case in my example above. Essentially, find a way to see the requirements in a new light, or from a different perspective, and the problems start to jump out at you.

The key is, no matter how you go about it, plan time to review the requirements in order to catch what's missed. Hopefully you'll find that nothing was missed! But if you do come across a missed requirement, remember that it's finding, not missing, the requirements that really matters!

Organizing Information – Part 1

Let’s say you have successfully gathered lots of requirements using various techniques and sources - now what? You are now faced with the daunting task of turning the chaos that we call “notes” into organized content in the form of a requirements specification.

At this point, you are likely in one of two situations:

1. You have a LOT of information that exists in either multiple documents or in many pages of one piece of documentation.

Example: A co-worker recently had been given 200 power point slides and 3
elicitation sessions worth of notes and had to turn this into clean requirements
for review by the business.

2. You have been able to run specific requirements sessions that allow you to contain the sources of the information, such that for a given topic, you only have 1-3 manageable sources of information.

Example: You ran 1 session on a topic, plus you were given 1 set of
requirements from a related project to roll-in. You need to create a
requirements specification on that topic.

You have more high-level organization to do in the first of these and lower level organization in the second. I am going to start by covering the first of these, in which you have chaos to organize.

Organization Approach

The approach is actually quite simple and engaging once you get started! Start by writing each concept or topic that you need to organize on a sticky note. Then begin to group the topics into categories. As you work through this, label the categories and add additional ones as necessary. At some point you step back to see if you need to group any categories together, break any apart or add new ones. It is an iterative approach to the organization, working at 2 different levels – the categories and where the topics go within the categories. What you end up with is a nice mapping of topics to categories and possibly groupings of categories.

You may see this model called an Affinity Diagram.

A few suggestions for executing this approach:

• When creating the groupings, target having approximately 5-9 categories as suggested by the 7 +/- 2 guideline.
• If you have more categories than that, that means you need to group your groups.
• While executing this organization technique, I highly recommend you physically get up and move around to do it. Use your walls or large flip chart paper and put the sticky notes on the wall.
• Move very quickly as you categorize topics. Trust your gut feel about which category to put an item in and do not over analyze it. Keep in mind, you can always move the items again – they are just sticky notes, not permanent marker!
• You can apply this technique by yourself or with a team.
• Name your groups with short names. Add a short description for others to know what you intend for the category to represent.

Practical example

We recently moved to SharePoint for our intranet content, and I had to move about 100 pieces of content over. I was unhappy with the previous structure of the content, so I really wanted to organize this one differently.

Before I started, I thought about the obvious categories – training, methodology, customer info. I worked with a small subset of the content and created additional categories to have a list that covered all of those topics. I took another step back from the topics and thought about the categories again. In doing so, I created one or two additional parallel categories, and I grouped some together. Then I went back to the topics and continued to assign them to categories. As you can see, I was just iterating back and forth between working at the category level and grouping the content into categories.

After a few iterations, I found that 95% of the content fit into the categories I had defined. I had a few pieces of content left that I had to look at again to determine - does it fit a category, do I redefine a category so it does fit or do I add a new category. And within no time at all, I had a nice organization of my intranet content on my whiteboard with sticky notes!

In other examples, you might use this approach on requirements projects to:

• Group features into functional areas of a system and organize your documentation accordingly
• Understand the different major components or systems of a large deployment and use them to plan your approach to gather requirements
• Organize multiple features that appear in multiple sources within a single organized format
• Working bottom-up, determine what the appropriate high-level features are for a system

Once the information is grouped, within each category you can apply different techniques to organize the information because you now have contained chaos. We’ll cover these in more detail in "Organizing Information - Part 2" next week!

Are your requirements smarter than a 5th grader?

There was a neat article in the July 13 Dr Dobbs Agile Modeling Newsletter.

http://www.ddj.com/dept/architect/201001273

It basically argued that you could evaluate the quality of a document based on a set of criteria:

C = The percentage of the document that is currently "correct".
R = The
chance that the document will be read by the intended audience.
U = The
percentage of the document that is actually understood by the intended audience.
F = The chance that the material contained in document will be followed.
T = The chance that the document will be trusted.

The CRUFT rating of the document, with 100% being a bad thing, is
calculated with the following formula:
100% - C * R * U * F * T

I thought this was a neat idea. I want to address the "U" factor that represents the chance that the document will be understood.



We generally have a clear idea in mind of who's going to read our document - business stakeholders, architects, developers, and testers. What we don't necessarily do well is to take into account what the people who perform these roles actually know about the system. If one of our objectives is to make our documents consumable by making them understandable, we need to be careful about how we present information.



One technique that I've often suggested that my clients use is to make sure that prose which gives context to the problem being solved should be understandable by a 5th grader. When I suggest this, many people insist that the problem is simply too complex. However, this is probably both overcomplicating your problem, and underestimating your 5th grader. If you can't explain your problem to a 5th grader, can you really explain it to a tester who has no context on the problem? Can you explain it to a business stakeholder who is brand new to his job?



In addition to facilitating communication with some consumers of the document, the act of breaking down a problem into simpler terms is a valuable exercise. It gives us a fresh perspective on the problem, and often allows us to challenge the assumptions that you've made in a more complex document.



So take a look at your last requirements document. Could a smart 5th grader understand them?

Meeting Management, Part 2

In the first part of this post, I covered some underlying principles to keep in mind when preparing for a meeting. This second part will pick up where that one left off, covering some suggestions for managing the meeting and moving forward once the meeting is over.

As a quick reminder, before the meeting begins you should determine whether to call the meeting, identify the goals of the meeting, identify the required attendees, select a time and location, and set and distribute an agenda. Then...

• Manage the discussion. When you start the meeting, briefly review the agenda to set expectations, explain your role and the roles of the participants, and lay out any applicable logistics or "rules of engagement" for the meeting. Provide any necessary background information. As the meeting progresses, make sure that it stays on topic and makes progress toward the stated goals. If things begin to veer off course, steer the discussion back to the topic at hand.
  
• Manage the time. Time management is a key aspect of running a successful meeting. You have a limited amount of time in which to meet your objectives, and your attendees have taken time out of their busy schedules to participate. Use a "parking lot" for discussions which can't be resolved in the time allotted. The parking lot isn't a way to get rid of a topic -- only to postpone discussion. Make sure to document any parking lot topics and return to them at the conclusion of the meeting.
• Wrap-up the meeting. At the end of the allotted time, wrap-up the discussion. Are there any open topics which weren't covered? What decisions were made? Are there any action items or to-do's for the meeting attendees? Set expectations regarding the timeframe for completing those tasks and how you will follow-up on them. And most importantly, thank the attendees for their time and effort.
  
• Follow through and follow up. Based on the tasks identified, follow through on the work each attendee (and you!) are responsible for. Make sure that those tasks are being completed, and share status with the other attendees so that everyone has visibility into the status.
  
• Solicit feedback and implement change. In order to improve your own meeting management skills, occasionally solicit feedback from the attendees. Ask them what went well and what could have been better in terms of the management of the meeting (rather than the content or the outcomes). Then take that feedback and determine if and how to change your approach for the next meeting.

Hopefully this overview will give you some ideas for improving your own meeting management. There are a number of great books on the topic, if you're interested in additional reading. Check out How to Make Meetings Work, The Art of Facilitation, Meeting Excellence, and Great Meetings! Great Results for more ideas. Also, I highly recommend re-reading All I Really Need to Know I Learned in Kindergarten too -- just as a reminder about how to treat others.

Design is a poor substitute for nonfunctional requirements

I've traditionally been somewhat neutral on what amount of design gets slipped into a requirements document. I'm a consultant, and to a certain extent, I'm willing to accept that the things that are important to a customer ARE the requirements, whether they are true "business requirements" or a design that indicates a choice by the customer to solve a business problem in a particular way.



What I don't like, however, is for design to be used as a substitute for non-functional requirements. Non-functional requirements are hard. It's not easy to define at an abstract level what your "usability" requirements are. Since people don't want to take on the hard task of defining "usability", they tend to instead simply "design" something that they think is "usable".



How do you know when this is happening? Take a look at the non-functional requirements section in a document. If it's small compared to the functional requirements, it's a good indication that someone has decided to use "design-like" functional requirements to get around doing a good job on the non-functional requirements.

Meeting Management, Part 1

I often hear people say that they spend too much time in meetings. And that got me thinking ... are we frustrated because of the amount of time we're spending in meetings, or are we frustrated because of problems with the meetings themselves? Is the problem not "how much" or "how many", but "how good"? For the sake of this post, let's assume that it is (work with me here!). So what can we do about it?

First, let's focus on some fundamental things to remember any time you're working with a group of people:

1. Be respectful. Respect other people, their ideas, their time and their perspectives. Require everyone else in the meeting to be respectful, too. There's no better way to alienate people, and therefore shoot your meeting in the foot, than to be disrespectful.
   
2. Be considerate. Closely linked to respect is consideration. Take others' needs into account when planning the meeting. While you can't necessarily choose a time, place or topic that will make all of the attendees jump for joy, you can (and should) take others' wants and needs into consideration.
3. Be nice. Some of the best advice I ever received was simple: "Be nice to each other." I'm often amazed at the ways in which people can express their "respect" or "consideration" for someone else's ideas by rolling their eyes, shaking their heads, crossing their arms, or sighing heavily. In meetings (and in the rest of life, too), be nice to each other in your interactions.

OK, so what are some ways to put these principles into practice when planning and facilitating a meeting?

• Determine whether to call the meeting. Does the meeting really need to occur? Could you gather the needed information from a phone call, email, or in-person interview?
  
• Identify the goals of the meeting. Determine what you want to accomplish within the meeting and as a result of the meeting. Do you want to brainstorm, share information, make decisions? What criteria will you use to determine whether the meeting was a success?
• Identify the required attendees. Once you know what you want to accomplish, you can determine the list of people required to reach that goal. Unless your goal is to spur discussion or brainstorm, it's typically better to keep the list of attendees as short as possible, while still allowing you to reach your objectives for the meeting.
• Select a time and location. Pick your time and location based on your participants' availability and your goals. Try to find a location which is convenient for all attendees, so that they don't have to spend a lot of time getting to and from the meeting. Be sure to choose a room that contains the tools you need (materials, AV, network connections, and seating to support your goals). Choose a time that is both available on your attendees' calendars and conducive to productive work. 4:30 on Friday afternoon may be free for everyone, but will they be focused on the task at hand?
• Set and distribute an agenda. Your meeting will be more productive if the attendees arrive ready to get to work. Prepare an agenda for the meeting which lists the time, location, attendees, and the topics you want to cover in the order you plan to cover them. Ask your attendees to send you any questions in advance so that you can clarify expectations and make any adjustments necessary before the meeting begins.
  

In the second part of this post, I'll cover the steps in facilitating the meeting and what to do after the meeting is complete.

The Magical Number Seven

This story may sound familiar to you.

A man decides to go to the store one Sunday morning to get a newspaper. Being the thoughtful husband he is he says to his wife “Honey, I’m going to the store for a newspaper, is there anything you need?” She replies “Oh, yes, could you get some bananas? We just ate the last one for breakfast. And, maybe some more eggs and some milk.” He says “Sure” and grabs his keys as he heads for the door. She opens the refrigerator and looks inside. “While you’re there, we need some carrots too, and some lemons, lettuce, and butter.” He pauses at the door. “Anything else?” “Well, yes” she says “Apples, potatoes, oh, and I guess we’ll need some sour cream.” “Ok” he says, and off he goes.

Maybe you’re better at this than I am but I would have a hard time repeating the shopping list without re-reading the paragraph above. There is some evidence that women are better at this than men (and half the people reading this are yelling “What do you mean SOME evidence”) but prior to the days of cell phones most men would return from the store with a newspaper and maybe the bananas.

Most of us would struggle to remember any unordered list of ten items without writing them down. When George A. Miller wrote about “The Magical Number Seven, Plus or Minus Two” he made the case that we can’t hold more than roughly seven to nine items in our short term memory at one time. This is a useful rule in many endeavors but especially so in grocery shopping, and software requirements.

One way to remember the shopping list is to group the items in some way. For example:

Dairy products

• Eggs


• Milk


• Butter


• Sour cream

Fruits

• Bananas


• Lemons


• Apples

Vegetables

• Carrots


• Lettuce


• Potatoes

By raising the level of abstraction and grouping related things together we greatly simplify the task of remembering. With only three things to remember (four if you count the newspaper) the husband has a chance of making it a successful shopping trip.

We can apply similar reasoning to simplify the task of comprehending and validating requirements. Comprehension of complex material is much easier if the material is logically presented, in a top-down manner, from one level of abstraction to the next. If it is not, then the audience must somehow find the connections and logical groupings on their own. With a large volume of material, that task is challenging, if not impossible.

It is a mistake to present our users with lists of hundreds of system shall statements or any other long lists of items. They may nod their heads but it is unlikely they comprehend what they are agreeing to. By using models to organize the material in a logical way we can make it possible for someone to actually understand what they are reading. They will be much more likely to spot missing or conflicting requirements. A requirements management tool that provides different views of the requirements can help but we can also change the way we think about requirements and the organization of the documents we produce. For example, a use case should ideally have nine or fewer steps in the main flow. At each level of detail we should remember the rule of seven plus or minus two.

Thanks to Barbara Minto for the idea for the shopping trip story.

An issue of understanding (users)

We deploy Sharepoint as one of the ways to collaborate on software projects. The basic organization of Sharepoint is a hierarchy of sites. Within those sites are lists and document libraries. The lists take the form of announcements, calendar entries and tasks. One of the key functions that is missing is a way to roll-up these lists from lower levels in the hierarchy to the higher levels. Microsoft provides a roll-up web part that somehwat satisfies this need by creating tabs for each site. If I want to see my tasks I have to click in each tab. This is hardly better than the default functionality.

Various companies have now made web parts that they sell for thousands of dollars specifically to create these roll-ups. If they are so useful, why didn't Microsoft include them? Was it just an oversight? Well it turns out it was a conscious decision on the part of the product management (requirements) team. Venky (Sharepoint Product Manager) is a very smart guy so why the oversight? There is a discussion on his Sharepoint blog here.

Venky writes:

There are two reasons why we choose to break up by tabs:

1. User Experience: Users are very comfortable with the idea of sites, its context and content in them. The tabs help organize information by that and break up what could be a very large list of items that will need to be rolled-up. Yes, we could have chosen to show the site as a piece of metadata and grouped-by or sorted-by that column, but that doesn't show the containership of the sites and its docs nearly as explicitly.

2. Technical: Because sites can be in any farm (in North America, Japan, Singapore and Dublin, in MS' case), doing a cross-farm, cross-site collection, cross-list query is NOT going to be fast and responsive, as a user would expect. That said, we could have used client-side scripting to pull all this info asynchronously, but then they wouldn't act as a single list easily. We didn't have the resources to build a complete list interaction model in Ajax in this version.

What we have found is that if you search the internet, many people are clamoring for true roll-up functionality. In fact Coras Works sells a roll-up Web part for thousands of dollars to satisfy this need. Venky's heart is in the right place. That tabs help to organize information for what could be a really long list is absolutely a true statement. The real question is whether tabs make it easier for the users to accomplish their tasks.

Here are some use cases that we have run into while creating Sharepoint communities.

Scenario 1
Each functional area in a company has calendar events, we want to roll those up into a company calendar so everyone can see a unified company calendar of all events. These events could be expense payments from finance, last day to to enroll for changes to benefits etc. People naturally classify by date (i.e. what is important in the near future) then by functional area, not the other way around, by functional area and then by date.

Scenario 2
Each functional area owns announcements, we want those to roll up to the top level so everyone can see the running list of announcements from any functional area. If at any given time only one tab has an announcement am I really going to keep clicking all 12 tabs to see if there is anything new?

Scenario 3
I have tasks in multiple functional areas (12) I need to prioritize between them, but I have no way to do this because they are all in different tabs.

If I were to imagine what the requirement might look like for this functionality it might be

The system shall provide a consolidated view of all their documents and tasks.

The current implementation satisfies the requirement, but the requirement doesn't satisfy the actual user needs.

We constantly have this debate within the requirements community. How much do you specify? Ultimately the goal of every software team is to provide software that satisfies the users actual needs. Staying focused on understanding how the users will accomplish their tasks is just as vital to understanding the tasks themselves.

Observing Users Work

When gathering requirements, one useful technique is to observe users work, rather than to simply interview them. If a task is complex, it may be hard for users to remember or articulate exactly the steps they go through to accomplish the task. It is much easier for them to just do it.



Watching users do their job will allow you to:

• Capture all of the steps of a task.


• Establish the context for an application. If you lack domain knowledge it is very useful to immerse yourself in the environment, as there are many contextual issues that users will simply not be aware of that you can understand by participating in the environment.


• Gain valuable information about the environment in which the user works (e.g. screen size, loudness of workspace, number of interruptions that occur, etc.).


• Measure the time taken to perform various tasks.


• Capture the details of a business process even when users are too busy to meet with you—they may continue to do their job while you watch.
  

Useful links:

http://www.codinghorror.com/blog/archives/000880.html

http://www.ddj.com/dept/architect/184415414


Book:



Observing the User Experience: A Practitioner’s Guide to User Research, by Mike Kuniavsky (http://www.amazon.com/exec/obidos/tg/detail/-/1558609237/ref=nosim/boxesandarrows-20)