Reaping the Benefits of Good User Requirements
From User Requirements to System Design
A critical part of any software development project is the requirements gathering. If you are unclear about what is going to be delivered, how will you know when you get there? Good user requirements lead to better estimates, improved customer satisfaction, reduced cost and a shorter duration. A few questions that need to be asked before the start of any software development project are:
* Why are we building the system?
* What benefits are we expecting to get from it?
* What do we actually need it to do?
A failure to gather business requirements or assuming we know what is required can lead to a poor outcome, requirement for extra resources, increased cost and longer duration.
As Frederick Brooks put it, "The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." [1]
Providing a Firm Foundation
Good requirements gathering provides a firm foundation from which to work. Customers need to know what is being developed and that it will satisfy their needs. Developers need to know what to develop and testers what to test. A quality requirements document can provide all of these things.
When creating a requirements document it is important to get everybody involved including the customer, project manager, customer account manager, developers, testers and anyone else with a stake in the project. Requirements gathering is a joint activity not solely the domain of business analysts and project managers.
A good set of requirements enables the project manager to plan and estimate the project effectively.
Running Requirements Meetings
The Requirements Gathering Meeting is the time to get all the team members, customers and stakeholders together to define the requirements for the system. Like all formal meetings, there should be an agenda. You need to cover a number of specific things at this meeting:
1. Introduction of the people at the meeting
2. The objectives of the meeting
3. The purpose of the project
4. The expected benefits
5. The customers' requirements
6. Next steps
Ideally, a business analyst should lead an open meeting where all ideas are encouraged to draw out the customer requirements. Customers are not always good at articulating their needs, so it is important to play back your understanding of their requirements to ensure clarity. Several meetings may be needed to gather all the requirements.
The requirements are written up by the business analyst in the Business Requirements Specification and are shared with the customer. The document must be clear, concise and thorough. The customer should review and agree the contents of the document. It is not advisable to ask them to physically sign it off, as this could be interpreted as a lack of trust and get the project off on the wrong-foot.
Including use cases in the Business Requirements Specification can be very useful for documenting business process and identifying different roles in the process. Customers often find the diagrams easier to understand than just plain text.
These are some of the rules for writing requirements documents:
* Requirements are written in the language of the user
* Avoid technical jargon
* Confirm what the system will not do, as well as what it will do
* Keep it clear, concise and thorough
* Include a section for non-functional requirements
Why Gather Requirements?
These are some of the reasons for gathering requirements:
* To group your thoughts and ideas in a logical way
* To group someone else's thoughts and ideas in a logical way
* To understand what a software package must do before making a selection
* To decide whether to buy or build a solution
* As a point of reference throughout the project
* To provide a basis for testing
Common Problems
These are some of the reasons given for not carrying out requirements gathering:
* No time because of tight deadlines
* Customer not available to meet and discuss requirements
* Requirements gathering seen as a waste of time by the organisation
* Assuming we know what the customer requires without asking
* No way of effectively recording requirements
* A dislike of requirements writing
Prototyping
When the customer finds it difficult to articulate their requirements, prototyping provides a low cost way to help them visualise a potential solution. Often customers are not entirely sure what they want (particularly in software development projects) and a prototype can help tease out their requirements.
A proof of concept may be required if the technology is innovative, or the project team are unfamiliar with it. A proof of concept confirms the IT department's capability to deliver the required solution.
System Design
Once you have established and agreed a clear set of requirements, the next step is to model a software solution. Using a recognised notation can be useful at this stage and help the team create a clear and unambiguous software design document.
Before building the solution, check the software design against the requirements to ensure that what you build meets the customers' needs. Revisit the requirements document regularly to ensure you are staying on-track.
"Modeling is the designing of software applications before coding." Object Management Group [2]. A popular notation for creating models of object-oriented software is the Unified Modeling Language (UML).
The Unified Modeling Language (UML)
The development of the Unified Modeling Language (UML) began in October 1994 and represents a unification of the concepts and notations of Booch, Rumbaugh and Jacobson. UML is a technology independent notation used for modeling systems using an object-oriented paradigm.
Terry Quatrani has defined the notation as, "… the standard language for specifying, visualizing, constructing and documenting all the artifacts of a software system." [3]
UML 2.0 is comprised of thirteen diagram types split into structure, behaviour and interaction.
Structure Diagrams emphasize what things must be in the system being modeled:
* Class diagram
* Component diagram
* Object diagram
* Composite structure diagram
* Deployment diagram
* Package diagram
Behaviour Diagrams emphasize what must happen in the system being modeled:
* Activity diagram
* Use Case diagram
* State Machine diagram
Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
* Sequence diagram
* Communication diagram (UML 2.0)
* Interaction Overview diagram (UML 2.0)
* Timing diagram (UML 2.0)
UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.
As well as for software design, UML notation can be useful during the requirements gathering stage. For instance, use case diagrams will show the users what they must do, as well as what the system will do for them. They can also be used as the basis for testing the application (creation of test plans) and development of user guides.
Good models ensure technical and architectural soundness, particularly for complex systems.
Critical Success Factors
To be successful at requirements gathering and to give your software development projects an increased likelihood of success:
* Don't assume you know what the customer wants, ask
* Involve the users from the start
* Define and agree the scope of the project
* Ensure requirements are specific, realistic and measurable
* Obtain clarity if there is any doubt
* Create a clear, concise and thorough requirements document and share it with the customer
* Confirm your understanding of the requirements with the customer (play them back)
* Avoid talking technology or solutions until the requirements are fully understood
* Get the requirements agreed with the stakeholders before the project starts
* Create a prototype if necessary to confirm or refine the customers' requirements
* Use a recognised notation, such as UML, for modeling the software
* Cross check the software design against the requirements and review regularly
UML Facts
* The development of UML began in October 1994
* UML represents a unification of the concepts and notations of Booch, Rumbaugh, and Jacobson.
* UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs
* UML is a popular notation for creating models of object-oriented software
* The current standard is UML 2.0 a major rewrite
* UML is technology independent and can be used for any type of software development
* Specific UML development tools exist, but the diagrams can created using programs such as Visio
* UML belongs to the Object Management Group (OMG) not Rational as many people believe