What types of requirements add the most value?

Question

I am looking for input on where developers find value in requirements.

I understand there are times and situations where requirements make a mess, but let's presume the person writing the requirements understands the business and what they need. Maybe requirements are needed for governance, or testing, or even because none of the coders understand the business. The question is, if you don't understand the need as well as the "writer," what will help you build a better mousetrap?

Presuming you work on enterprise applications in a corporation and the life-cycle is closer to Waterfall than it is to Agile, please include details about not only what adds value, but why.

If you like UML, which part? Do you like use cases diagrams, but not the textual information that comes with it? What about data flow diagrams? Process flows? "System shall" statements? Business rule charts?

Help me understand so I can write better stuff for you to use. Heck, even feedback on what you hate and why would be helpful.

Answer 1

Just give me some functional specifications that describe what the thing needs to do, in as much detail as possible. Wireframes are very helpful, much more so than UML diagrams. Just don't tell me how to design the thing behind the scenes.

Answer 2

Requirements should tell me what to develop or architect. No more and no less. I find that good requirements are not explaining the obvious, but are also unambiguous on complex points. UML diagrams are fine, as long as they are needed and are the clearest way of explaining a requirement.

Requirements are like code comments, they should clarify the complex part, but not explain the obvious. :)

Answer 3

It might help for me to tell you about the requirements I get and what I don't like about them. One of my clients gives me a Word doc written up by marketing and approved by IT. This is about as raw as requirements can be. Talk about ambiguity.

Here's where the magic takes place: I translate this in to what I think it means as far as a set of features that takes the form of a list of questions and a list of assumptions. I then run these by the client, who, fortunately, is available via email or IM.

Req docs are ambiguous at best, and outright deceptive at worst. So, what adds value? Access to the customer.

I do web apps, not industrial-strength software, but I still maintain that frequent customer feedback and high customer availability are essential (the customer may be a client or it may be your PM). Those are tenets of extreme programming and probably some other methodologies, but I think they are good rules of thumb in any project.

Answer 4

A good requirement should be one that help testers to design UAT (User Acceptance Test) (this is not the only criteria)

When a new release is defined (what is called a 'Top Content', that is, when the release manager decide of the next functional perimeter will be for the next code release), the selected user requirements should be listed, and the UAT designed.
During that time, all developments related to that perimeter are merged into a release-specific environment in order to meet those requirements.
Then the homologation phase checks if the code meets those user demands.

Considering that scenario, a requirement is, IMO, not so much about what to develop, but about what to test in the end.

Answer 5

Don't forget to collect "non-functional" requirements. These are thing like expectations for reliability, security, performance, scalability, configurability, etc. They're often referred to as the "ility" attributes. See http://en.wikipedia.org/wiki/Ilities. I've seen multi-million dollar software projects fail on the day they were supposed to go live because these concerns were not properly addressed.

Answer 6

In a business context, the best requirements are ones that are phrased like a story describing a problem and details around it, while not attempting to describe a solution as well:

• Who has the problem? (Describe this person, perhaps as a "persona")
• What are the goals of the persona? (What does he/she need to achieve?)
• Which use scenarios would be useful for the persona? (Describe interactions)

If there are non-functional requirements associated with the problem (scale, response time, security, etc), they should be made clear separately.

If this is done well, developers can figure out how to solve the problem and implement a solution: solving problems is what developers do! Of course, figuring out the personas, use scenarios, goals, etc is hard and requires a lot of footwork, interacting with customers and potential customers to really determine what problems they have that they also have money available to solve :)