Software Best Practices

When I teach our requirements seminar, I'm frequently hit with questions about knowing when the requirements work is done. Most often it is asked when the client divides the requirements in separate specifications (e.g. Marketing Requirements Documents, Product Requirements Specifications, Software Requirements Specification, etc).  I get the sense that the questioner is really looking for ammo to bang on somebody -- "See I was right, Jerry said the MRD must be 30,000 words!" Ok, I admit this is a slight exaggeration; but you get this point.

I have my standard "It depends" answer, but I would like to hear from you.   How do you know when the requirements are good enough?  

Jerry,

That is a good question. As you know (since we work together) I have four loose criteria I use do judge "done".

1. Are the requirements sufficient to answer the question at hand?
2. Are they appropriate given the next consumers?
3. Do they meet basic goodness checks?
4. Is the feedback from key stakeholders positive?

The summary of these four areas, the bottom line, is: Are the requirements able to convey information to the next person so that they can do their job correctly? That is all I really need for requirements. The consumer needs information to do their job. Everything else is just an aid to get the information there in a correct, usable state.

Earl,

Oh no, you revealed the consultant's secret "It Depends" answer. As you know, I completely agree with the good enough criteria you listed. 

 Still I'm looking forward to hearing how other people determine when the requirements are done.

Well the simple answer is they are never done and they will always change even when you are midway through development. Not that this is necessarily a bad thing if you have a proper change management process.

I'd judge a requirement is 'done' when anyone that looks at it knows what it means. E.g. a Project Manager, Customer and Developer can all look at it and come to the same conclusion about what it means and have a common understanding of what it will look like when it is implemented and delivered.

So for any requirement:

1. Is there a common understanding of what it means?
2. Is it testable?
   
3. Is it implementable?
   
4. Is there a common understanding of what it will look like or what it will enable someone to do when implemented?

David,

I agree with your comment: 

David Harper:

the simple answer is they are never done

That's why the question always drives me crazy. For some weird reason, people want to ignore the reality and live in the fantasyland where requirements get done. "If we would only have more time in the requirements phase!"

That leads to the real question that Earl alludes to -- Done in what context?   Are they done enough to determine the scope boundaries, enough to create initial estimates, or enough to implement the feature?   The answer is different in each case.

In the end, then this means the requirements writer cannot say that the requirements are complete - it's up to the requirements consumers (e.g. estimators, developers, testers, etc) to say that they are good enough for them to complete their work.

The idea that requirements cannot be done completely is the main reason for the classic waterfall life cycle to be considered obsolete. Requirements are totally done and finished when the application is released. Even in the testing phase our tester finds some conflicts or ambiguity in the requirements- or in the best case he may suggest a slight modification for the ease of usability or giving the application some consistency.

For us, Requirements are sufficient when they define the screens of the application.Our requirements are always accompanied by screens for the application (created using Excel), or screens for the part of the application that will be implemented in the current stage of the project plan. Here we can move to the next phase - which is putting a general software architecture for the application. Of course requirements are changed and detailed during the project's life cycle after that but defining the application screens is a good start point to move to the next phase.

Simple answer (where I am)  is that they are 'done' when the business signs them off as done!

David

I think your list is a good one in terms of how the analyst and the business lead agree on whether they are suffieciently complete for development to start,

David Harper:

1. Is there a common understanding of what it means?
2. Is it testable?
   
3. Is it implementable?
   
4. Is there a common understanding of what it will look like or what it will enable someone to do when implemented?
   

 

Though the the implementable part doesn't get addressed in detail  at requirements definition stage. Which is not to say that we specify requirements that are not implementable - just that the detail of implementation isn't always included in the requirement.

As has been said, requirements are never 100% done, and even if they could be, the requirement may well change before a systems  implementation.

iforsyth:

Though the the implementable part doesn't get addressed in detail  at requirements definition stage.

I agree, notice that I didn't say in detail. Perhaps feasible might have been a better word. But I think it is important to have a conversation between whoever is writing and agreeing the requirements with the people that are going to be responsible for making it happen. Something along the lines of "Hey people, do you think you can do this?".

 The worse possible outcome, which I've seen many times, is you will get a requirement given to you that technically isn't feasible or even make sense. Something along the lines of "What on earth are they smoking, don't they know protocol X doesn't do this, what they should be doing is using protocol Y?".

 
I think my point here is get the technical people to review the requirements - don't let them get a shock later on.

 

 Good point David:

David Harper:

The worse possible outcome, which I've seen many times, is you will get a requirement given to you that technically isn't feasible or even make sense.

This goes to the point I raised earlier that the requirements consumers (e.g. estimators, developers testers, etc) have a very strong vote on when the requirements are complete.  This is the basis of the review process. 

However, waiting for the review process may be too long. Ronald Mascitelli offers a lean technique for this - previews.  Why wait until you're finished writing the document to find out you're on the wrong track.  Instead talk to the consumers and find out what they need to know and what issues they expect you to address in the requirements.  Let them preview the drafts, while they're still in outline form, so they can tell you if you're on the right track.

(FYI - Ronald Mascitelli is the author of: Building a Project-Driven Enterprise: How to Slash Waste and Boost Profits Through Lean Project Management)

Hi, there,

I just found this forum and the discussions seem very interesting, so I decided to join.

I like the answers given to the question, but I think there's one important criterion that wasn't mentioned yet:

-> Does the requirements address all important scenarios/conditions/user behaviors?

(I.e., the requirements need to, besides answering the question at hand, etc.,  be considered "complete enough". Of course, requirements completeness is not something that can be easily measured, but I think that to consider "requirements done", one should at least attempt to verify that most scenarios, exceptions and "goal thwarthing" possibilities have been considered.).

What are your thoughts?

I think that is a fair start though I like to use models to help me understand if I really am complete in terms of user behaviors. Models tend to show that stuff is missing more readily to me than plain text.

I usually have a better feeling if I have several behaviors that we identified and determined were out of scope for this project.

Oh, absolutely. I didn' t mean to imply that plain text would be a good reference for answering the "level of completeness" question.

Even if using models to answer the question, I think that this is a check point question to include while asssessing "requirements doneness": for all things determined to be in scope, verify that most - if not all - potential alternatives of behavior/path were considered, not only the most probable  path.