Chapter 3 Understanding Requirements

1
Chapter 3 Understanding Requirements

• Requirements
• Vision
• Use-Case Modeling
• Software Requirements Specification
• Requirements Management
• Case Study and Project

2
Requirements
3
3.1 Requirements

• What is Requirements
• Types of Requirements
• Requirements Documents

4
What is requirement?

• Requirements are capabilities and conditions to
  which the system (and more broadly, the project)
  must conform. JBR99.
• The purpose of Requirements is
• To provide system developers with a better
  understanding of the system requirements.
• To define the boundaries of (delimit) 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.

5
Requirements

• Factors on challenged software projects
• 37 of factors related to problems with
  requirements,

6
Requirements Management

• Requirements management is a systematic approach
  to
• eliciting, organizing, and documenting the
  requirements of the system
• establishing and maintaining agreement between
  the customer and the project team on the changing
  requirements of the system.
• Keys to effective requirements management
  include
• maintaining a clear statement of the
  requirements, along with applicable attributes
  for each requirement type
• traceability to other requirements and other
  project artifacts.

7
Types of Requirements FURPS

• Functional
• features, capabilities, security.
• Usability
• human factors, help, documentation.
• Reliability
• frequency of failure, recoverability,
  predictability.
• Performance
• response times, throughput, accuracy,
  availability, resource usage.
• Supportability
• adaptability, maintainability, internationalizatio
  n, configurability.

8
Types of Requirements FURPS

• The "" in FURPS indicates ancillary and
  sub-factors, such as
• Implementation
• resource limitations, languages and tools,
  hardware, ...
• Interface
• constraints imposed by interfacing with external
  systems.
• Operations
• system management in its operational setting.
• Packaging
• Legal
• licensing and so forth.

9
Types of Requirements RUP

• Requirements are categorized as functional
  (behavioral) or non-functional (everything else)
• Functional Requirements
• Functional requirements are explored and recorded
  in
• the Use-Case Model
• the system features list of the Vision artifact.
• Non-functional Requirements
• Other requirements can be recorded in the use
  cases they relate to, or in the Supplementary
  Specifications artifact.

10
Requirement Documents

• Vision
• The Vision artifact summarizes high-level
  requirements that are elaborated in these other
  documents.
• The Vision is a general vision of the core
  project's requirements, and provides the
  contractual basis for the more detailed technical
  requirements.
• Include
• Problem Statement
• User or Stakeholder Descriptions
• Product Overview
• Features
• Constraints

11
Requirement Documents

• SRS (Software Requirements Specification)
• Functional requirements
• Use case Model
• Non-functional requirements
• Supplementary Specification
• Glossary
• records and clarifies terms used in the
  requirements.
• also encompasses the concept of the data
  dictionary, which records requirements related to
  data, such as validation rules, acceptable
  values, and so forth
• User-Interface Prototype
• Prototypes are a mechanism to clarify what is
  wanted or possible.

12
Requirement Artifacts in UP
13
Vision
14
3.2 Vision

• Introduction
• Template
• Example
• How to develop Vision

15
Vision - Introduction

• The Vision document provides
• a complete vision for the software system under
  development and supports the contract between the
  funding authority and the development
  organization.
• The vision document is
• written from the customers' perspective,
• focusing on the essential features of the system
  and acceptable levels of quality.
• The Vision should include
• a description of what features will be included
  as well as those considered but not included.
• It should also specify operational capacities
  (volumes, response times, accuracies), user
  profiles (who will be using the system), and
  inter-operational interfaces with entities
  outside the system boundary, where applicable.
• The Vision document provides the contractual
  basis for the requirements visible to the
  stakeholders.

16
Vision - Introduction

• The Vision document
• is created early in the inception phase, and
• it is used as a basis for the Business Case and
  the first draft of the Risk List
• The Vision document
• serves as input to use-case modeling, and
• is updated and maintained as a separate artifact
  throughout the project.

17
Vision - Introduction

• Purpose of Vision
• Gain agreement on what problems need to be
  solved.
• Identify stakeholders to the system.
• Define the boundaries of the system.
• Describe primary features of the system.

18
Vision - Template for small project

• 1. Introduction
• 2.  Positioning          
• 2.1     Problem Statement      
• 2.2     Product Position Statement     
• 3.  Stakeholder and User Descriptions  
• 3.1     Stakeholder Summary     
• 3.2     User Summary
• 3.3 Key High-Level Goals and Problems of the
  Stakeholders
• 3.4 User-Level Goals     
• 3.5     User environment 

19
Vision - Template for small project

• 4.  Product Overview      
• 4.1     Product Perspective     
• 4.2     Assumptions and Dependencies     
• 5.  Product Features         
• 5.1     ltaFeaturegt     
• 5.2     ltanotherFeaturegt     
• 6.  Other Requirements and Constraints      

20
Vision - Commentary to Template

• Problem Statement      
• Provide a statement summarizing the problem being
  solved by this project.
• The following format may be used

The problem of describe the problem
affects the stakeholders affected by the problem
the impact of which is what is the impact of the problem?
a successful solution would be list some key benefits of a successful solution
21
Vision - Commentary to Template

• Product Position Statement       
• Provide an overall statement summarizing, at the
  highest level, the unique position the product
  intends to fill in the marketplace.
• The following format may be used

For target customer
Who statement of the need or opportunity
The (product name) is a product category
That statement of key benefit that is, the compelling reason to buy
Unlike primary competitive alternative
Our product statement of primary differentiation
22
Vision - Commentary to Template

• User Summary       
• Present a summary list of all identified users.
• The following format may be used

Name Description Responsibilities Stakeholder
Name the user type. Briefly describe what they represent with respect to the system. List the users key responsibilities with regard to the system being developed for example captures details produces reports coordinates work and so on If the user is not directly represented, identify which stakeholder is responsible for representing the users interest.
23
Vision - Commentary to Template

• Product Perspective       
• This subsection puts the product in perspective
  to other related products and the users
  environment.
• If the product is independent and totally
  self-contained, state it here.
• If the product is a component of a larger system,
  then this subsection needs to relate how these
  systems interact and needs to identify the
  relevant interfaces between the systems.
• One easy way to display the major components of
  the larger system, interconnections, and external
  interfaces is with a block diagram.
• System context diagram
• High-level deployment diagram

24
Vision - Commentary to Template

• Product Features       
• Use cases are not necessarily the only way one
  needs to express functional requirements.
• An alternative, a complementary way to express
  system functions is with features, or more
  specifically in this context, system features,
• System features are high-level, terse statements
  summarizing system functions.
• A system feature is "an externally observable
  service provided by the system which directly
  fulfills a stakeholder need" Kruchten00.
• Features are things a system can do.
• The point of system features in the Vision is
• to summarize the functionality,
• not decompose it into a long list of fine-grained
  elements.
• Keep feature descriptions at a general level.
• Focus on capabilities needed and why (not how)
  they should be implemented.
• Avoid design.
• It is common to organize a two-level
  hierarchy

25
Vision - Commentary to Template

• Other Requirements in the Vision      
• In the Vision, system features briefly
  summarize functional requirements expressed in
  detail in the use cases.
• Likewise, the Vision can summarize other
  requirements (for example, reliability and
  usability) that are detailed in the Special
  Requirements sections of use cases, and in the
  Supplementary Specification (SS).

26
Vision - Example

• Course Registration System example
• Vision 1
• NextGen example

27
Vision - How to develop Vision

• Gain agreement on the problem being solved
• Identify stakeholders
• Define the system boundaries
• Identify constraints to be imposed on the system
• Formulate problem statement
• Define features of the system
• Evaluate your results

28
Vision - Checkpoints

• Have you fully explored what the "problem behind
  the problem" is?
• Is the problem statement correctly formulated?
• Is the list of stakeholders complete and correct?
  
• Does everyone agree on the definition of the
  system boundaries?
• If system boundaries have been expressed using
  actors, have all actors been defined and
  correctly described?
• Have you sufficiently explored constraints to be
  put on the system?
• Have you covered all kinds of constraints - for
  example political, economic, and environmental.
• Have all key features of the system been
  identified and defined?
• Will the features solve the problems that are
  identified?
• Are the features consistent with constraints that
  are identified?

29
3.3 Use-Case Modeling

• Key Concepts
• Use-Case Diagram
• Use-Case Specification
• Relationship between Use-case
• Checkpoints

30
Key Concepts
31
What Is System Behavior?

• System behavior is how a system acts and reacts.
• It is the outwardly visible and testable activity
  of a system
• System behavior is captured in use cases.
• Use cases describe the system, its environment,
  and the relationship between the system and its
  environment.

32
What Is a Use-Case Model?

• A model that describes a systems functional
  requirements in terms of use cases
• A model of the systems intended functionality
  (use cases) and its environment (actors)

View Report Card
Register for Courses
Student
Login
33
What Are the Benefits of a Use-Case Model?

• Used to communicate with the end users and domain
  experts
• Provides buy-in at an early stage of system
  development
• Insures a mutual understanding of the
  requirements
• Used to identify
• Who interacts with the system and what the system
  should do
• The interfaces the system should have
• Used to verify
• All requirements have been captured
• The development team understands the requirements

34
Major Concepts in Use-Case Modeling

• An actor represents anything that interacts with
  the system.
• A use case is a sequence of actions a system
  performs that yields an observable result of
  value to a particular actor.

Actor
Use Case
35
What Is an Actor?

• Actors are not part of the system.
• Actors represent roles a user of the system can
  play.
• They can represent a human, a machine, or another
  system.
• They can actively interchange information with
  the system.
• They can be a giver of information.
• They can be a passive recipient of information.

Actor
Actors are EXTERNAL.
36
Useful Questions in Finding Actors?

• Who will supply, use, or remove information?
• Who will use this functionality?
• Who is interested in a certain requirement?
• Where in the organization is the system used?
• Who will support and maintain the system?
• What are the systems external resources?
• What other systems will need to interact with
  this one?

37
Focus on the Roles

• An actor represents a role that a human, hardware
  device, or another system can play.

38
A User May Have Different Roles
39
Practice Find the Actors

• In the Course Registration System Requirements
  document, read the Problem Statement for the
  Course Registration case study.
• As a group, identify the following
• Actors
• Description of the actor

40
Practice Solution
A person who is registered to take courses at the
University
The external system responsible for student
billing
The unabridged catalog of all courses offered by
the University
A person who is teaching classes at the University
The person who is responsible for the maintenance
of the course registration system
41
What Is a Use Case?

• A sequence of actions a system performs that
  yields an observable result of value to a
  particular actor

42
Use Cases and Actors

• A use case models a dialog between actors and the
  system.
• A use case is initiated by an actor to invoke a
  certain functionality in the system.

Communicates Association
43
How to Find Use Cases

• Answer the following questions to find use cases.
• For each actor you have identified, what are the
  tasks the system would be involved in?
• Does the actor need to be informed about certain
  occurrences in the system?
• Will the actor need to inform the system about
  sudden, external changes?
• What information must be modified or created in
  the system?

44
Naming the Use Case

• The name indicates what is achieved by its
  interactions with the actor(s).
• The name may be several words in length.
• No two use cases should have the same name.

45
Use-Case Diagram
46
Use case diagram

• Captures system functionality as seen by users
• Built in early stages of development
• Purpose
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts and domain experts

47
How Would You Read This Diagram?
View Report Card
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor
Submit Grades
Close Registration
Billing System
48
Use Case Diagram - Example
Development Manager
49
Use-Case Specification
50
Use-Case Specifications

• Name
• Brief description
• Flows of Events
• Relationships
• Activity diagrams
• Use-Case diagrams
• Special requirements
• Pre-conditions
• Post-conditions
• Other diagrams

51
Use-Case Specifications - Flow of Events

• A use case describes what a system (or a
  subsystem, class, or interface) does but it does
  not specify how it does it.
• You can specify the behavior of a use case by
  describing a flow of event in text clearly enough
  for outsider to understand it easily.
• When you write this flow of events, you should
  include how and when the use case starts and
  ends, when the use case interacts with the actors
  and what objects are exchanged, and the basic
  flow and alternative flow of the behavior.

52
Use-Case Flow of Events

• Has one normal, basic flow
• Several alternative flows
• Regular variants
• Odd cases
• Exceptional flows handling error situations

53
Use-Case Specifications - Scenarios

• A use case actually describes a set of sequences
  in which each sequence in the set represents one
  possible flow through all those variations.
• A scenario is a specific sequence of actions that
  illustrates behavior.
• Scenarios are to use cases as instances are to
  classes, meaning that a scenario is basically one
  instance of a use case.

54
What Are Scenarios ?

• A scenario is an instance of a use case

55
What Is an Activity Diagram?

• An activity diagram in the use-case model can be
  used to capture the activities in a use case.
• It is essentially a flow chart, showing flow of
  control from activity to activity.

Flow of Events This use case starts when the
Registrar requests that the system close
registration. 1. The system checks to see if
registration is in progress. If it is, then a
message is displayed to the Registrar and the use
case terminates. The Close Registration
processing cannot be performed if registration is
in progress. 2. For each course offering, the
system checks if a professor has signed up to
teach the course offering and at least three
students have registered. If so, the system
commits the course offering for each schedule
that contains it.
56
Example Activity Diagram
Activity State
delete course
Decision
Delete Course
add course
Select
Course
Concurrent threads
Synchronization Bar (Fork)
Check
Check
Schedule
Pre-requisites
Transition
Guard Condition
Synchronization Bar (Join)
checks failed
checks completed
Resolve
Assign to
conflicts
course
student added to the course
Update
schedule
57
Use-Case Specifications - Example
- User Management
1. Brief Description This use case is for
adding and deleting users. When adding user, the
privilege of the user will be assigned.2. Basic
Flow B1. Start of use case Actor
chooses User Management in main screen. B2.
Prompt welcome screen System shall prompt
actor the user management welcome screen.
A1. Choose delete user B3. Choose add
user Actor chooses Add User. B4. Prompt
add user screen System shall prompt actor
the add user screen which needs actor to input
some information. These information include
User Name, User ID, User Password, User Role.
B5. Submit Actor inputs the information
and submits the screen. E1. User ID
already exists E2. Not enough information
B6. Prompt success System shall prompt
actor success information.
58
Use-Case Specifications - Example
3. Alternative FlowsA1. Choose Delete User
From B2. Prompt welcome screenA1.1 Choose
delete Actor chooses delete user.A1.2
Prompt delete user screen System shall
prompt actor the delete user screen. In this
screen, system shall lists all the user ID stored
in system.A1.3 Choose user to delete Actor
chooses the user ID to delete and submit this
screen.




E3. No user ID chosenA1.4 Prompt
success System shall prompt actor success
information.
4. Exception FlowsE1. User ID already exists
From B5. Submit, The User ID actor inputs has
already existed in the system. The system shall
prompt actor to try another User ID?E2. Not
enough information From B5. Submit, If actor
does not input all the information, system can
not add a user. The system shall prompt actor to
input all the information.E3. No user ID chosen
From A1.3 Choose user to delete, If actor
does not choose a user to delete before
submitting the screen, the system shall prompt
actor an error that he/she should choose a user
to delete.
59
Relationship between Use-Case
60
Relationship between Use-case (optional)

• include
• extend
• generalization

61
Relationship between Use-cases - include
ltltincludegtgt An include relationship from use
case A to use case B indicates that an instance
of the use case A will also contain the behavior
as specified by B. The behavior is included at
the location which defined in A.
62
Relationship between Use-cases - include
ltltincludegtgt Functional Decomposition
Problem w A function in the original problem
statement is too complex to be solvable
immediately
Solution w Describe the function as the
aggregation of a set of simpler functions. The
associated use case is decomposed into smaller
use cases
63
Relationship between Use-cases - include
ltltincludegtgt Reuse of Existing Functionality
Problem w There are already existing functions.
How can we reuse them?
Solution w The include association from a use
case A to a use case B indicates that an instance
of the use case A performs all the behavior
described in the use case B (A delegates to B)
Example w The use case ViewMap describes
behavior that can be used by the use case
OpenIncident (ViewMap is factored out)
Note w The base case cannot exist alone. It is
always called with the supplier use case
Base Usecase
Supplier Usecase
64
Relationship between Use-cases - extend
ltltextendgtgt An extend relationship from use case
A to use case B indicates that an instance of use
case B may be augmented (subject to specific
conditions specified in the extension) by the
behavior specified by A. The behavior is inserted
at the location defined by the extension point in
B which is referenced by the extend relationship.
Request additional credit information
ltltextendgtgt
Evaluate loan request
Refer loan request to loan committee
ltltextendgtgt
65
Relationship between Use-cases - extend
Problem w The functionality in the original
problem statement needs to be extended.
Solution w An extend association from a use case
A to a use case B indicates that use case B is an
extension of use case A.
Example w The use case ReportEmergency is
complete by itself , but can be extended by the
use case getHelp for a specific scenario in
which the user requires help
Note w In an extend assocation, the base use
case can be executed without the use case
extension
66
Relationship between Use-cases - Generalization

• With the introduction of UML 1.3, a new
  relationship between use cases was introduced -
  generalization
• Generalization A generalization from use case
  A to use case B indicates that A is a
  specialization of B.

67
Relationship between Use-cases - Generalization
Problem w You have common behavior among use
cases and want to factor this out.
Solution w The generalization association among
use cases factors out common behavior. The child
use cases inherit the behavior and meaning of the
parent use case and add or override some behavior.
Example w Consider the use case ValidateUser,
responsible for verifying the identity of the
user. The customer might require two
realizations CheckPassword and
CheckFingerprint
Parent usecase
Child usecase
68
Checkpoints
69
Checkpoints Requirements Use-Case Model

• Is the use-case model understandable?
• By studying the use-case model, can you form a
  clear idea of the system's functions and how they
  are related?
• Have all functional requirements been met?
• Does the use-case model contain any superfluous
  behavior?
• Is the division of the model into use-case
  packages appropriate?

70
Checkpoints Requirements Actors

• Have all the actors been identified?
• Is each actor involved with at least one use
  case?
• Is each actor really a role? Should any be
  merged or split?
• Do two actors play the same role in relation to a
  use case?
• Do the actors have intuitive and descriptive
  names? Can both users and customers understand
  the names?

71
Checkpoints Requirements Use-Cases

• Is each use case involved with at least one
  actor?
• Is each use case independent of the others?
• Do any use cases have very similar behaviors or
  flows of events?
• Do the use cases have unique, intuitive, and
  explanatory names so that they cannot be mixed up
  at a later stage?
• Do customers and users alike understand the names
  and descriptions of the use cases?

72
Checkpoints Requirements Use-Case Specifications

• Is it clear who wishes to perform a use-case?
• Is the purpose of the use-case also clear?
• Does the brief description give a true picture of
  the use-case?
• Is it clear how and when the use-case's flow of
  events starts and ends?
• Does the communication sequence between actor and
  use-case conform to the user's expectations?
• Are the actor interactions and exchanged
  information clear?
• Are any use-cases overly complex?

73
Review Requirements Overview

• What are the main artifacts of Requirements?
• What are the Requirements artifacts used for?
• What is a use-case model?
• What is an actor?
• What is a use case? List examples of use case
  properties.
• What is the difference between a use-case and a
  scenario?
• What is a supplementary specification and what
  does it include?
• What is a glossary and what does it include?

74
3.4 Software Requirements Specification

• Identifying other requirements
• Supplementary Specifications
• Glossary

75
Supplementary Specifications
76
Supplementary Specification

• Functionality
• Usability
• Reliability
• Performance
• Supportability
• Design constraints

77
Supplementary Specification - Example

• Review the Supplementary Specification provided
  in the Course Registration Requirements Document

78
Glossary
79
Glossary
Course Registration System Glossary 1.        Intr
oduction This document is used to define
terminology specific to the problem domain,
explaining terms, which may be unfamiliar to the
reader of the use-case descriptions or other
project documents. Often, this document can be
used as an informal data dictionary, capturing
data definitions so that use-case descriptions
and other project documents can focus on what the
system must do with the information. 2.        
Definitions The glossary contains the working
definitions for the key concepts in the Course
Registration System. 2.1       Course A class
offered by the university. 2.2       Course
Offering A specific delivery of the course for a
specific semester you could run the same
course in parallel sessions in the semester.
Includes the days of the week and times it is
offered. 2.3      Course Catalog The unabridged
catalog of all courses offered by the university.
80
Glossary - Example

• Review through the Glossary provided in the
  Course Registration Requirements Document

81
3.5 Requirements Management

• Making sure you
• Solve the right problem
• Build the right system
• By taking a systematic approach to
• eliciting
• organizing
• documenting
• and managing
• the changing requirements of a software
  application.

82
Aspects of Requirements Management

• Analyze the Problem
• Understand User Needs
• Define the System
• Manage Scope
• Refine the System Definition
• Build the Right System

83
Map of the Territory
Problem Space
Problem
Needs
Solution Space
Features
Traceability
Use Cases and Software Requirements
84
3.6 Case Study and Project

• Inception Phase
• Case Study - CRS
• Project - Inception Phase

85
Inception Phase
86
Inception Phase

• Inception Phase Define the scope of the
  project and develop business case
• The primary objectives of the inception phase
  include
• Establishing the project's software scope and
  boundary conditions, including an operational
  vision, acceptance criteria and what is intended
  to be in the product and what is not.
• Discriminating the critical use cases of the
  system, the primary scenarios of operation that
  will drive the major design trade-offs.
• Exhibiting, and maybe demonstrating, at least one
  candidate architecture against some of the
  primary scenarios
• Estimating the overall cost and schedule for the
  entire project.
• Estimating potential risks.
• Preparing the supporting environment for the
  project.

87
What Artifacts May Start in Inception?
Artifact Comment
Vision and Business Case Describes the high-level goals and constraints, the business case, and provides an executive summary.
Use-Case Model Describes the functional requirements, and related non-functional requirements.
Supplementary Specification Describes other requirements.
Glossary Key domain terminology.
Risk List Risk Management Plan Describes the business, technical, resource, schedule risks, and ideas for their mitigation or response.
Prototypes and proof-of-concepts To clarify the vision, and validate technical ideas.
Iteration Plan Describes what to do in the first elaboration iteration.
Phase Plan Software Development Plan Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources.
Development Case A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project.
88
Inception Phase - a suggested sequence

• 1. Write a brief first draft of the Vision.
• 2. Identify user goals and the supporting use
  cases.
• 3. Write some use cases and start the
  Supplementary Specification.
• 4. Refine the Vision, summarizing information
  from these.

89
Checkpoint What Happened in Inception?

• Inception is a short step
• to determine basic feasibility, risk, and scope.
• Some likely activities and artifacts in
  inception include
• a short requirements workshop
• most actors, goals, and use cases named
• most use cases written in brief format 10-20 of
  the use cases are written in fully dressed detail
  to improve understanding of the scope and
  complexity.
• most influential and risky quality requirements
  identified
• version one of the Vision and Supplementary
  Specification written
• risk list
• technical proof-of-concept prototypes and other
  investigations to explore the technical
  feasibility of special requirements
• user interface-oriented prototypes to clarify the
  vision of functional requirements
• recommendations on what components to
  buy/build/reuse, to be refined in elaboration
• high-level candidate architecture and components
  proposed
• plan for the first iteration
• candidate tools list

90
Sample requirements effort across the early
iterations
91
Case Study (Covered in GCIS501)
92
Case Study - Course Registration System

• Vision
• SRS - Use Case Model
• SRS - Supplementary Specification
• SRS - Glossary

93
Project Inception Phase
94
Project - Requirements

• Work as a team (max 3 person)
• Select topic
• Write the following Requirements artifacts
• Vision
• SRS
• Use-case model(Use-case diagram, Use-case
  specification, Activity Diagram)
• Supplementary specification
• Glossary
• User Interface (optional)