Reaping the Benefits of Good User Requirements with UML

Reaping the Benefits of Good User Requirements

From User Requirements to System Design

By Duncan Haughey

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:

Introduction of the people at the meeting
The objectives of the meeting
The purpose of the project
The expected benefits
The customer's requirements
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.
The current standard is UML 2.0 a major rewrite
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
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

References

No Silver Bullet: Essence and Accidents of Software Engineering, Frederick P Brooks. Addison Wesley.
Introduction to OMG's Unified Modeling Language, Object Management Group
Introduction to the Unified Modeling Language, Terry Quatrani, Rational

Add this article to:

4-Developers.com

Menu: