How do you write good softwarerequirements?

I'm looking for characteristics of good software requirements. Also, what methodology/processes/ techniques do you follow or tools you use to write good software requirements.
Who is Participating?
huferryConnect With a Mentor Commented:
the proces methodology '(Rational) Unified Process' covers the whole steps from definition to deployment. UP is usually used with UML. I think UP is ideal to use as software development process.
From my view, characteristic of a good requirement:
- clear and can be easily read by the client --> without any software/techincal terms that the client does not use. A good requirement is written in client-domain terms.
- requirement defines WHAT to build and not HOW it's going to be built.
- describe the system in use-cases. Use cases can be easily read by the client. You can support the use-cases with UML's use-case diagrams.

The tool that supports UP/UML -> Rational rose.
MurpheyConnect With a Mentor Application ConsultantCommented:
Hi WarBabies,

Softwarerequirements is the hardest part of the documentation in a project, do it the right way and a user will NOT understand what it all mean (to technical). During the past 25 years I discover that the best way for the user to read and for the programmer/analyst to understand, is to describe the process in a normal readable language without technical details and mention everyting you need to know as of you write the story of the user/customer for someone else to understand. Ask a "super-user" to help you, (Not a manager, they know what is happening in global lines, but most of the time they are not aware on the very important details).
Never think "they know what I mean", but discribe everything.
If the user use the words "Always" or "Never" be aware he means most of the time :)

Start with the following alinea's:
-What is te purpose
(Just a short part of 2 or 3 lines)
- Who will work with it
(this will guarantee that, once the requirement is signed, no other persons or departments will complain
about missing functionality, because if they are not mentioned here, it's not for them to use)
- Why do they need it
(This is important to let the user explain why he thinks he needs it)
- What are the requirements
(Number every requirement in the story, to link technical stuff to in a next step)
e.g. The user needs to enter a 6 digit field (1) , that must be an existing  customer-    number (2) leaving this field blank or enter a wrong number will give an error (3).

Let the user (or customer) participate as much as possible in this process, it must be his story in your words that you put on paper, this will take some extra time, but you will compensate that in a later stap in the process.
Regards and good luck,
DarrenDConnect With a Mentor Commented:

I would say much the same as murphey2. I mainly use UML to create a use case overview of requirements and then use documentation to describe each use case in detail.

It is difficult to design exact requirements in a single document as it sometimes starts running away with itself as some stuff belongs in more technical documents. Also the part of keeping documentation up-to-date becomes anoying but in the long run it really helps, not only for yourself but also for anyone else comming onto the project.

But if you can come up with the main functionality that will be used by each user of the system such as 'Make Supplier Payment' or 'Create Order' then you should be able to describe (with the help of the business people) the process in more detail and also show what information should be automatically generated by the system and what should be input by the user as well as discovering further requirements. Then as murphey2 said create a story or flow of how the application will be used.

Maybe something like:

1 Requirements Overview

1.1 Login

1.2 Create Customer

1.3 Process Order

Then just describe in simple english exactly what happens.
1.2 Create Customer
User enters the following information
Address etc...

State which fields are mandatory etc...

From this you will get a better overall and indepth picture of the system and should be able to develop all of the screens, interfaces, classes and database tables that you require to build the system.

Hope this helps,


Jeff CertainCommented:
We're using user stories. This allows our domain experts to specify the system in a language they understand, and helps prevent them from getting too technical. This is a great approach is you're in an environment where you're working closely with your clients, since the user story is really just the beginning of a conversation. Short iterations allow the client to give us continual feedback to make sure we don't go down the wrong path for too long.
Mike Cohn is one of the experts in the field. His site has some good articles on user stories ( and he's got a couple book sout on making them good.
I really, really have to disagree with murphey2 that "do it the right way and a user will NOT understand what it all mean." Requirements that the client can't understand give you no mechanism to determine whether you've met their requirements.
Having said that, there will be functional specs and design documents that the client won't understand -- but they don't need to; those are internal artifacts only.
All Courses

From novice to tech pro — start learning today.