Understanding Requirements

2
Requirements

“The hardest single part of building a software system is deciding what

to build. No part of the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later.”

- Fred Brooks

3
Requirements
• Requirements are statements that describe the users’ or stakeholders’
needs and desires with respect to the software in question

• Each requirement:
• Is a short and concise piece of information
• Says something about the software system
• Is agreed upon by stakeholders
• Helps solve the customers’ problems

4
Requirements Engineering
• Requirements engineering is the process of developing a complete
requirements specification for a project
• This process entails the following:
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirements management

5
Requirements Engineering
• Inception—Ask a set of questions that establish …
• A basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired, and
• The effectiveness of preliminary communication and collaboration
between the customer and the developer
• Elicitation—Acquire requirements from all stakeholders
• Elaboration—Create an analysis model that identifies data, function
and behavioral requirements

6
Requirements Engineering
• Negotiation—Agree on a deliverable system that is realistic for
developers and valuable to customers
• Specification—Can be any one (or more) of the following:
• A written document (for example, a Software Requirements
Specification or SRS)
• A set of graphical models
• A formal mathematical model
• A collection of user scenarios (use cases)
• A prototype

7
Requirements Engineering
• Validation—A review mechanism that looks for
• Errors in content or interpretation
• Areas where clarification may be required
• Missing information
• Inconsistencies (a major problem when large products or systems are
engineered)
• Conflicting or unrealistic (unachievable) requirements
• Requirements management—Mechanisms to help the team identify,
control, and track requirements and changes to requirements

8
Establishing the Groundwork
• Identify stakeholders
• Stakeholders are “anyone who benefits in a direct or indirect way from
the system which is being developed”
• The goal is to create a list of people who will contribute input as
requirements are elicited.
• Don’t be afraid to ask “Who else do you think I should talk to?”
• Recognize multiple points of view
• Every stakeholder will have their own perspective and point of view
• While this might lead to inconsistent or conflicting requirements, it is
critical to embrace and take advantage of the diversity of opinions here

9
Establishing the Groundwork
• Work toward collaboration
• Identify areas of commonality and areas of conflict or inconsistency, and bring
people together to express their views on requirements to guide final decisions
• The first questions:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
• These questions identify all the stakeholders, the benefits of a successful
implementation and possible alternatives to custom development

10
Establishing the Groundwork
• The next questions:
• How would you characterize “good output” generated by a successful solution?
• What problem(s) will this solution address?
• Can you show or describe the environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is
approached?
• These questions enable you to get a better understanding of the
problem and allows the stakeholder to voice his or her perceptions
about a solution

11
Establishing the Groundwork
• And, finally ask:
• Are you the right person to answer these questions? Are your answers “official”?
• Are my questions relevant to the problem that you have?
• Can anyone else provide additional information?
• Should I be asking you anything else?
• Am I asking too many questions?
• These “meta questions” focus on the effectiveness of the
communication activity itself and can be quite useful

12
Collaborative Requirements Gathering
• A collaborative approach to requirements gathering applies some
variation of the following guidelines:
• Meetings are conducted and attended by both software engineers and customers
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage a free flow of ideas
• A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting
• A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room or virtual forum) is used

13
Collaborative Requirements Gathering
• The goal here is:
• To identify the problem
• Propose elements of the solution
• Negotiate different approaches, and
• Specify a preliminary set of solution requirements

• As requirements are gathered, an overall vision of system functions and

features begins to materialize

14
Elicitation Work Products
• A variety of work products can be created by requirements elicitation:
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who participated in the process
• A description of the system’s technical environment
• A list of requirements (preferably organized by function) and the domain
constraints that apply to each
• A set of usage scenarios that provide insight into the use of the system or product
under different operating conditions
• Any prototypes developed to better define requirements

15
Functional Requirements
• Specific behaviors that describe what the system should “do”
• These can include:
• Stakeholder functions and features that are required
• Data, format, and information needs
• System interfaces or services used
• Specific interface requirements

16
Non-Functional Requirements
• Constraints that must be adhered to during development that
describe how the system should “be” or “come to be”
• Three main types:
• Quality requirements, including both evolutionary quality (reliability,
maintainability, testability, and reusability) and execution quality (security,
response time, throughput, usability)
• Platform requirements, including the environments, platform(s), and
technologies of the system
• Process requirements, including planning and development constraints,
costing, delivery date(s), and delivery constraints

17
Use Cases
• Use cases are a collection of user scenarios that describe the thread
of usage of a system
• Use cases make it easier to understand how the functions and
features of a system will be used by different classes of end users
• This, in turn, facilitates more technical software engineering activities
• Use cases can take many forms, including narrative text, an outline of
tasks or interactions, a template-based description, or a diagrammatic
representation (in the case of a UML use case diagram)

18
Use Cases: Actors
• Each scenario is described from the point of view of an “actor”—a
person or device that interacts with the software in some way
• It is important to note that an actor and an end user are not
necessarily the same thing
• A typical user may play a number of different roles when using a
system, whereas an actor represents a class of entities that play just
one role in the context of the use case
• Understanding actors is a critical part of understanding requirements

19
Use Cases: Actors
Actor: The actor’s name.
Description: Brief description of the actor and its role in the system. This description should
be no more than a small paragraph and should give the reader an
understanding of the role of the actor in the organization.

Aliases: Any other names by which this actor may be known. A simple list is sufficient.
Say ‘None’ if there are none.
Inherits: The ancestors for the actor. Some actors may be specialized types of other
actors. A simple list of the names of the ancestors will suffice. Say ‘None’ if
there are none.
Actor Type: Whether the actor is a person or an external system, as well as other forms of
typing (e.g. are they an API, hardware device, etc.).

Active/Passive: If this actor is active or passive. They are the ones who initiate a use case. In
most cases active actors both send and receive input/output from the system.
Passive actors are part of a use case but do not initiate it and are not the main
focuses of the case (e.g. they may only receive output or only give input after
the case is triggered). 20
Use Cases: Scenarios
• Each scenario answers the following questions:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What extensions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about external environment changes?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?

21
 Use Cases: Scenarios
Use Case: A name given to the use case.
Primary Actor: The main actor in the use case; the use case is from their perspective.
Secondary Actor: Other actors involved in the use case.
Goal in Context: The overall scope of the use case, provides a brief description of the use case and its purpose.
Preconditions: What is known to be true before the use case is initiated.
Trigger: What event or condition gets the use case started or invoked.
Scenario: A numbered series of steps that capture the narrative of the use case, outlining what the
actors do in this use case and what happens as a result.
Alternatives: If alternative behaviour is possible at any of the steps outlined in the Scenario, it should be
described here in a similar fashion. Say 'None' if there is no such alternative behaviour.
Exceptions: Identify potential issues or situations that may arise from the various steps of this use case.
Priority: One of: Highest, High, Medium, Low, Lowest. This is the priority your team is assigning to this
use case (how important it is to implement, how essential it is to the function and goals of
the application, etc.).
….Extra Fields… Additional headings and information may be provided as you deem necessary. 22
Example Use Case

23
Example Use Case
Actor: Homeowner
Description: The homeowner interacts with the home security system using the
control panel, tablet, or cell phone. They are the end user of the
system and control the arming/disarming of the system.

Aliases: User, End User

Inherits: None

Actor Type: Person, End User

Active/Passive: Active

24
Example Use Case

Use case: Initiate Monitoring

Primary actor: Homeowner
Goal in context: To set the system to monitor sensors when the homeowner
leaves the house or remains inside
Preconditions: System has been programmed for a password and to
recognize various sensors
Trigger: The homeowner decides to “set” the system, that is, to turn
on alarm functions

25
Example Use Case
Scenario:
1. Homeowner observes control panel
2. Homeowner enters password
3. Homeowner selects “stay” or “away”
4. Homeowner observes alarm light to indicate that SafeHome has been armed
Exceptions:
1. Control panel is not ready. Homeowner checks all sensors to determine which are open and closes them.
2. Password is incorrect (control panel beeps once). Homeowner reenters correct password.
3. Password not recognized. Monitoring and response subsystem must be contacted to reprogram password.
4. “Stay” is selected. Control panel beeps twice and a “stay” light is lit. Perimeter sensors are activated.
5. “Away” is selected. Control panel beeps three times and and “away” light is lit. All sensors are activated.

26
Example Use Case

Priority: Essential, must be implemented

When available: First increment
Frequency of use: Multiple times per day
Channel to actor: Via control panel interface
Secondary actors: System administrator, sensors
Channels to System administrator: phone line
secondary actors: Sensors: hardwired and radio frequency interfaces

27
Example Use Case

Open Issues:
1. Should there be a way to activate the system without the use of a password or with an
abbreviated password?
2. Should the control panel display additional text messages? What about voice messages?
3. How much time does the homeowner have to enter the password from the time the first
key is pressed?
4. Is there a way to deactivate the system before it actually activates?

28
Use Case Diagrams
• Use case diagrams are a visual way of capturing use cases
• Typically, a use case diagram is an overview of all use cases (at least
from a key actor’s perspective) and how they are related
• As such, use case diagrams provide a big picture of the functionality
of the software system in question
• Use case diagrams are a part of UML

29
Wait … You Never Said What UML Was!
• UML stands for Unified Modeling Language
• Unified: It brings together several techniques and notations for design, and
has been standardized (first by the Object Management Group in 1997 and
then by the International Organization for Standardization in 2005)
• Modeling: It describes a software system and its design at a high level of
abstraction
• Language: It provides the means to communicate this design in a logical,
consistent, and comprehensible fashion

30
Wait … You Never Said What UML Was!
• Goals of UML
• Enable the modeling of object-oriented designs
• Visually depict various aspects of the overall design of a solution
• Provide extensibility and specialization mechanisms to extend core concepts
• Be independent of particular programming languages and development
processes
• Support higher-level development concepts such as collaborations,
frameworks, patterns, and components

31
Wait … You Never Said What UML Was!
• Each UML diagram allows developers and customers to view a
software system from different perspectives and from different levels
of abstraction
• Some examples:
• Structure diagrams (class, component, object, …)
• Behaviour diagrams (use case, activity, …)
• Interaction diagrams (sequence, timing, …)

32
Okay … Back to Use Case Diagrams
• Actors
• A stick figure in a use case diagram represents an actor that is associated with
one category of user (or other interaction element)
• Complex systems might have more than one actor
• Use cases
• Use cases are displayed as ovals
• The actors are connected by lines to the use cases that they carry out
• Use cases are placed in a rectangle, but that actors or not; the rectangle is a
visual reminder of the system boundaries and that the actors are outside of
the system

33
Example Use Case Diagram

34
Final Thoughts on Use Case Diagrams
• Use case diagrams are helpful in ensuring that you have covered all of
the functionality of the system as you get to see the system as a whole
• Note that none of the details of use cases are included in the
diagrams, however, and such details need to be stored separately
• These details are still important to the software development process,
and are often considered to be more important that the overall use
case diagram

35
Building a Requirements Model
• A requirements model is an analysis model
• The intent of this model is to provide a description of the required
informational, functional, and behavioral domains for a computer-
based system
• This model changes over time as you learn more about the system
and as other stakeholders learn more about what they really require

36
Building a Requirements Model
• There are many ways to look at the requirements of a software
system, and so there can be many elements of a requirements model
• Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the system
• Class-based elements
• Implied by scenarios
• Behavioral elements
• State diagram
• Flow-oriented elements
• Data flow diagram

37
Example Class Diagram (More on this Soon)

From the SafeHome system …

38
Example State Diagram (More on this Soon)

From the
SafeHome
system …

39
Negotiating Requirements
• Ideally, inception, elicitation, and elaboration tasks determine
requirements cleanly and in sufficient detail to move forward
• This rarely happens in reality, and some form of negotiation is necessary
• In negotiation, stakeholders are asked to balance functionality,
performance, and other product or system characteristics against cost
and time-to-market needs
• The intent of negotiation is to develop a project plan that meets
stakeholder needs while at the same time reflecting the real world
constraints on the project

40
Negotiating Requirements
• Negotiation typically involves:
• Identification of key stakeholders who will be involved in the negotiation
• Determination of each of the stakeholder’s “win conditions”, which are not
always obvious
• Negotiation of the stakeholders’ various win conditions to reconcile them to a
set of “win-win” conditions for all concerned
• Successful completion of these steps achieves a win-win result that
gets the majority of stakeholder needs met, while doing so in a way
that is achievable by the team considering time and budget constraints

41
Validating Requirements
• As each element of the requirements model is created, it is examined
for inconsistency, omissions, and ambiguity
• A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of abstraction? That is,
do some requirements provide a level of technical detail that is inappropriate at
this stage?
• Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?

42
Validating Requirements
• More questions:
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house
the system or product?
• Is each requirement testable, once implemented?

43
Validating Requirements
• Even more questions:
• Does the requirements model properly reflect the information, function and
behavior of the system to be built.
• Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system.
• Have requirements patterns been used to simplify the requirements model.
Have all patterns been properly validated? Are all patterns consistent with
customer requirements?

44
Requirements Monitoring
• Monitoring is especially needed in incremental development to ensure
that requirements continue to be met over time
• Distributed debugging – uncovers errors and determines their cause
• Run-time verification – determines whether software matches its specification
• Run-time validation – assesses whether evolving software meets user goals
• Business activity monitoring – evaluates whether a system satisfies business
goals
• Evolution and codesign – provides information to stakeholders as the system
evolves

45