Requirements workflow

The goals of the workflow

• To establish and maintain agreement with the customers and other stakeholders
on what the system should do—and why!
• To provide system developers with a better understanding of the system
requirements
• To define the boundaries of the system
• To provide a basis for planning the technical contents of iterations
• To provide a basis for estimating cost and time to develop the system
• To define a user interface for the system, focusing on the needs and goals of
the users

A requirement is defined as a condition or capability to which a system must

conform.

Activity: Listing candidate requirements

A workshop or brainstorming session involving Users, customers, analysts, and

developers may be organized for this purpose.

• Features often originate in the experience that customers or users have with the
existing system or similar systems.
• Some features originate in the interaction between the software organization
and the users.

Activity: Capture functional requirements: These are the capabilities that the
proposed system is required to possess.

The straightforward approach to identifying system requirements is based on use-

cases. To identify the use-cases required by the users, we need to understand the
system context, interview users, discuss proposals, and so on.
Activity: Find actors and use-cases
A workshop or brainstorming sessions led by system analyst can be useful for this
purpose. The other participants include project manager, architect, developer, client,
and users.

With vision document, feature list, and the business model as inputs, the sessions
involve the following steps.

Task: Identify actors

Task: Identify use cases.
Task: For each of the identified use cases, determine whether it requires interaction
with other users or systems.
If necessary, repeat first three steps.

Task: Briefly describe each actor and use-case.

Task: Create a Glossary containing the key "items" the application deals with.

Task: Describe the use-case model as a whole. Use-case diagrams are used for this
purpose.

Activity: Prioritize use-cases

• Use cases representing the main functions of the system are the critical use
cases.
• In addition use cases that have important non-functional requirements such as
performance, response time, and so on, are also critical.
Critical use cases are architecturally significant, and hence get higher priority.
Workers: Project manager, Architect
Artifact: Architectural view of the use-case model.
Activity: Detail critical use cases.
The main purpose of detailing a use-case is to describe its flow of events in detail,
including how the use-case starts, ends and interacts with actors.
With the use-case model as input, the use-case specifiers work closely with the real
users of the use-cases to detail the step-by-step description of each use-case.
Use case name ReportEmergency
Participating Initiated by FieldOfficer
actors Communicates with Dispatcher
Flow of events 1. The FieldOfficer activates the “Report
Emergency” function of her terminal.
2. FRIEND responds by presenting a form to the
FieldOfficer.
3. The FieldOfficer completes the form by
selecting the emergency level, type, location and brief
description of the situation. The FieldOfficer
also describes possible responses to the emergency
situation. Once the form is completed, the
FieldOfficer submits the form.
4. FRIEND receives the form and notifies the
Dispatcher.
5. The Dispatcher reviews the submitted information
and creates an Incident in the database by
invoking the OpenIncident use case. The
Dispatcher selects a response and acknowledges
the report.
6. FRIEND displays the acknowledgement and
the selected response to the FieldOfficer.
Entry condition The FieldOfficer is logged into FRIEND.
Exit conditions The FieldOfficer has received an acknowledgement
and the selected response from the Dispatcher
OR
The FieldOfficer has received an explanation
indicating why the transaction could not be processed.
Quality The FieldOfficer’s report is acknowledged within 30
requirements seconds.
The selected response arrives no latter than 30 seconds
after it is sent by the Dispatcher.

A use case description should

• Define the start state as a precondition.

• Describe how and when the use-case starts.
• Describe the order in which the actions must be performed.
• Describe how and when the use case ends.
• Describe possible end states.
 • Describe alternative path descriptions.
• Describe interaction between system and actors by explicitly describing what
the system does and what the actors do.

A use case can be thought of as having a start state, intermediate states, and end
states. Transition from one state to another is triggered by an event such as a message
exchange. If there are many states and transition paths, a textual use-case description
becomes difficult. In such cases

• UML statechart diagrams can be used for visual modeling.

• Activity diagrams can be used to describe the transitions in more detail.
• Interaction diagrams can be used to describe how a use case instance interacts
with instances of actors.

During inception phase, many of the alternative flows may be postponed until later in
the project, as long as they do not have a major impact on the architecture.

Capturing nonfunctional requirements: These are the conditions the system is

required to possess. These requirements are generally in the form of usability,
reliability, performance, and supportability.

Most of these requirements are relevant only to a certain use-case and are specified
along with the detailed use-case description.

The general non-functional requirements are specified as supplementary requirements. Some of

these are very important in this phase as they suggest the platform, middleware architecture etc.