How do you write good softwarerequirements?

Posted on 2009-04-22
Last Modified: 2013-11-12
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.
Question by:WarBabies
    LVL 3

    Accepted Solution

    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.
    LVL 16

    Assisted Solution

    by:theo kouwenhoven
    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,
    LVL 18

    Assisted Solution


    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,


    LVL 24

    Expert Comment

    by:Jeff Certain
    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.

    Featured Post

    What Security Threats Are You Missing?

    Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

    Join & Write a Comment

    Suggested Solutions

    Author Note: Since this E-E article was originally written, years ago, formal testing has come into common use in the world of PHP.  PHPUnit ( and similar technologies have enjoyed wide adoption, making it possib…
    Software development teams often use in-memory caches to improve performance. They want to speed up access to, or reduce load on, a backing store (database, file system, etc.) by keeping some or all of the data in memory.   You should implement a …
    Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    755 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now