Dr. Thomas Hicks

1
Software EngineeringCSCI 3321
Requirements Engineering
Dr. Thomas Hicks Computer Science
Department Trinity University
7
1
2
Chapter 7
Software Engineering A Practitioners Approach
RequirementsEngineering Dr. Thomas E.
HicksComputer Science DepartmentTrinity
University Thanks To Ian Sommerville Roger
Pressman For Much Of The Slide Content
3
RequirementsEngineering
4
Requirements Engineering Cant Be Too Hard Can It?

• Creating the Requirements/Specifications cant be
  too hard can it?
• After All the user does know what he/she wants
  dont they?

YES
NO
Pressman It Is Your Worst Nightmare!
5
What Is Requirements Engineering?

• Requirements Engineering is the set of processes
  used to discover, analyze and validate system
  requirements.
• Requirements Engineering helps software engineers
  to better understand the problem they will work
  to solve.
• Requirements Engineering encompasses the set of
  tasks that leads to an understanding of what the
  business impact of the software willbe, what the
  customer wants, and howthe end user will
  interact with the software.

6
Requirements Elicitation Process Activities

• Domain Understanding
• Requirements Collection
• Classification
• Conflict Resolution
• Prioritization
• Requirements Checking

7
RequirementsEngineeringProcesses

8
Requirements Engineering Management

• 4 Analysis Design Processes
• Inception - ask questions to understand people
  problem
• Elicitation - elicit requirements from all
  stakeholders
• Elaboration - create an analysis model that
  identifies data, function and behavioral
  requirements
• Negotiation - agree on a deliverable system that
  is realistic for developers and customers
• 2 Post Analysis Design Processes
• Validation - demonstrating that the requirements
  define the system that the customer really wants
• Requirements Management - managing changing
  requirements

9
Requirements Engineering Management

• The Processes used for Requirements Engineering
  can vary widely depending on the application
  domain, the people involved and the organization
  developing the requirements
• They can vary like the processes in the Waterfall
  Model.
• For purposes of our exams, we shall use the
• 4 Analysis Design Processes
• 2 Post Analysis Design Processes
• illustrated in these slides.

10
Requirements Engineering4 Analysis
Design Processes Inception
11
Requirements Engineering Inception - 1

• It is the function of the Inception
  stage/function of Requirements Engineering to ask
  a set of questions that establish
• Basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired
• The effectiveness of preliminary communication
  and collaboration between the customer and the
  developer

Important Stage Get In Or Get Out!
12
Requirements Engineering Inception - 2

• Identify stakeholders
• who else do you think I should talk to?
• Recognize multiple points of view
• Work toward collaboration
• 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?

13
Requirements Engineering4 Analysis
Design Processes Elicitation
14
Requirements Engineering Elicitation - 1

• Requirements Elicitation is the process of
  combining the technical staff with the customers
  to work out
• the User Requirements Customers,
• the System Requirements Contract, and
• the Software Specification Developers
• Requirements Elicitation is also called
  Requirements Discovery
• Objectives Of Requirements Elicitation
• Determine the application domain
• Determine the services that the system should
  provide
• Determine the systems operational constraints

15
Elicitation Meeting GuidelinesRequirements
Engineering

• Meetings are conducted and attended by both
  software engineers and customers
• Rules for preparation and participation are
  established
• An agenda is suggested
• 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
• The goals are
• To identify the problem
• To propose elements of the solution
• Negotiate different approaches, and
• Specify a preliminary set of solution
  requirements

16
Requirements Elicitation Participants

• Requirements Elicitation participants may involve
  
• End-Users - receivers of system services
• Managers
• Engineers involved in Maintenance
• Domain Experts
• Trade Unions, etc.
• Those individuals have a stake in the system
  they are called Stakeholders

17
Eliciting Requirements Flowchart
18
Elicitation Work Products Might Include

• 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 requirements
  elicitation
• A description of the systems 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.

19
Feasibility Study Designer Questions

• A Feasibility Study decides whether or not the
  proposed system is a worthwhile venture
• A Designer Portion of the Feasibility Study is a
  short focused study that checks
• If the system contributes to organizational
  objectives
• If the system can be engineered using current
  technology and within budget can the critical
  specifications can be met?
• If the system can be integrated with other
  systems that are used

20
Feasibility Study Stakeholder Questions

• A Stakeholder Portion of the Feasibility Study is
  a short focused study that checks
• What if the system wasnt implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed?
• Will new user training be necessary?

21
Viewpoint-Oriented Elicitation

• Stakeholders represent different ways of looking
  at a problem or problem viewpoints
• This multi-perspective analysis is important as
  there is no single correct way to analyze system
  requirements
• Viewpoints are a natural way to structure
  requirements elicitation
• It is relatively easy to decide if a viewpoint is
  valid

22
ATMBankingExample
23
Banking ATM System Example

• Auto-Teller - provides some automated banking
  services
• Simplified System - offers some services to
  customers of the bank
• Narrower range of services to customers
• Services include cash withdrawal, message passing
  (send a message to request a service), ordering a
  statement and transferring funds

24
Auto Teller ViewpointsWho Would Be The
Stakeholders

• Bank Customers

Others? You Do!

• Representatives Of Other Banks
• Hardware Software Maintenance Engineers
• Marketing Department
• Bank Managers Counter Staff
• Database Administrators Security Staff
• Communications Engineers
• Personnel Department

25
Method-Based Analysis

• There are Structured Methods to help the project
  manager to organize and categorize views. VORD
• Methods have different emphases. Some are
  designed for requirements elicitation, others are
  close to design methods
• A Viewpoint-Oriented Requirements Definition
  (VORD) is one of the more common models.
• Widely used approach to requirements analysis.

26
VORD Method Flow4 Basic Steps
Viewpoint-Oriented Requirements Definition
VORD is an acronym for ___________________________
__
Viewpoint-Oriented Requirements Definition
27
4 Step VORD Process Model

• Viewpoint Identification
• Discover viewpoints which receive system services
  and identify the services provided to each
  viewpoint
• Viewpoint Structuring
• Group related viewpoints into a hierarchy. Common
  services are provided at higher-levels in the
  hierarchy
• Viewpoint Documentation
• Refine the description of the identified
  viewpoints and services
• Viewpoint-System Mapping
• Transform the analysis to an object-oriented
  design Use Case

28
Viewpoint Identification - ATMMany Can Views
Which Help Determine Others
29
Viewpoint Structuring - Hierarchy
30
Viewpoint Documentation VORD Standard Forms
31
Viewpoint Documentation Customer/Cash
Withdrawal VOID Templates
32
Viewpoint DocumentationVOID Data/Control
33
Requirements Engineering4 Analysis
Design Processes Negotiation
34
3 Major Steps In Negotiating Requirements

• Identify the key stakeholders
• These are the people who will be involved in the
  negotiation
• Determine each of the stakeholders win
  conditions
• Win conditions are not always obvious
• Negotiate
• Work toward a set of requirements that lead to
  win-win

35
Requirements Engineering4 Analysis
Design Processes Elaboration
36
Requirements Engineering Elaboration

• Elaboration - create an analysis model that
  identifies data, function and behavioral
  requirements
• We have already examined, briefly, a number of
  different models.

37
Building the Analysis Model

• Elements of the analysis 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

38
Requirements Engineering Scenarios

39
ScenariosHelp To Describe Exceptions

• Scenarios are descriptions of how a system is
  used in practice
• They are helpful in requirements elicitation as
  people can relate to these more readily than
  abstract statement of what they require from a
  system
• Scenarios are particularly useful for adding
  detail to an outline requirements description
• Scenarios map nicely to Use-Case Diagrams

40
Exception Description Problem In Most Structured
Methods

• Most Structured Scenarios Methods do not include
  facilities for Describing Exceptions
• In the ATM example, exceptions are
• Timeout. Customer fails to enter a PIN within the
  allowed time limit
• Invalid Card. The card is not recognised and is
  returned
• Stolen Card. The card has been registered as
  stolen and is retained by the machine

41
Scenario Descriptions Inclusions

• System State at the Beginning of the scenario
• Normal Flow of Events in the scenario
• What can go wrong and how this is handled Early
  Risk Analysis
• Other Concurrent Activities
• System State on Completion of the scenario

42
Event Scenarios

• Event scenarios are used to describe how a system
  responds to the occurrence of some particular
  event such as start transaction
• VORD includes a Diagrammatic Convention for Event
  Scenarios.
• Data Provided Delivered
• Control Information
• Exception Processing
• The Next Expected Event

43
Event Scenario - Start Transaction VORD
Diagrammatic Convention
44
Scenario Notation 1 Data Control Analysis

• Ellipses. data provided from or delivered to a
  viewpoint
• Control information enters and leaves at the top
  of each box

45
Scenario Notation 2 Data Control Analysis

• Data leaves from the right of each box
• Exceptions are shown at the bottom of each box
• Name of next event is in box with thick edges

46
Use Cases 1Object Oriented Notations

• Use-Cases are a scenario based technique in the
  UML which identify the Actors in an interaction
  and which describe the interaction itself

Your Group May Have Different Names For The
Actors OK If Descriptive
Teachers?
UML is an acronym for ?
Unified Modelling Language
47
Use Cases 2Object Oriented Notations
UseCases have become a fundamental feature of
UMLIntroduced by Jacobson in 1993

• A set of use cases should describe all possible
  interactions with the system

Actors
The Stick Figures Are Called _____________________
_
Interactions
The Ellipses Represent __________________________
48
Use Cases 3Object Oriented Notations
The Stick Figures Are Called _____________________
_
Actors
The Ellipses Represent __________________________
Interactions
49
Library Use-Cases
50
Catalogue ManagementUML Sequence Diagram
Who Are The Actors?
What Are The Objects?
The Sequence Of Actions Is From The Top To The
Bottom
51
Use-Cases

• A collection of user scenarios that describe the
  thread of usage of a system
• Each scenario is described from the point-of-view
  of an actor - a person or device that interacts
  with the software in some way
• Each scenario answers the following questions
• Who is the primary actor, the secondary actor
  (s)?
• What are the actors 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 actors interaction are
  possible?
• What system information will the actor acquire,
  produce, or change?
• Will the actor have to inform the system about
  changes in the external environment?
• What information does the actor desire from the
  system?
• Does the actor wish to be informed about
  unexpected changes?

52
Use-Case Diagram
53
Class Diagram
From the SafeHome system
54
State Diagram
55
The Specification/RequirementsDocument

56
The Specifications/Requirements Document

• Specification - can be any one (or more) of the
  following
• A written document
• A set of models
• A formal mathematical
• A collection of user scenarios (use-cases)
• A prototype

57
Requirements Engineering2 Post-Analysis
Design Processes Validation
58
Requirements Engineering Validation5 Major
Things Validation Attempts To Determine

• 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.

59
Requirements Validation

• Validation is concerned with demonstrating that
  the requirements define the system that the
  customer really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error

60
9 Validating Requirements Guidelines - 1

1. Is each requirement consistent with the overall
   objective for the system/product?
2. 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?
3. Is the requirement really necessary or does it
   represent an add-on feature that may not be
   essential to the objective of the system?
4. Is each requirement bounded and unambiguous?
5. Does each requirement have attribution? That is,
   is a source (generally, a specific individual)
   noted for each requirement? Who wanted it?

61
9 Validating Requirements Guidelines - 2

1. Do any requirements conflict with other
   requirements?
2. Is each requirement achievable in the technical
   environment that will house the system or
   product?
3. Is each requirement testable, once implemented?
4. Does the requirements model properly reflect the
   information, function and behaviour of the system
   to be built.

62
5 Abreviated Validation Requirements Check Points

• Validity. Does the system provide the functions
  which best support the customers needs?
• Consistency. Are there any requirements
  conflicts?
• Completeness. Are all functions required by the
  customer included?
• Realism. Can the requirements be implemented
  given available budget and technology?
• Verifiability. Can the requirements be checked?

63
Requirements Validation Techniques

• Requirements Reviews
• Systematic manual analysis of the requirements
• Prototyping
• Using an executable model of the system to check
  requirements.
• Test-Case Generation
• Developing tests for requirements to check
  testability
• Automated Consistency Analysis
• Checking the consistency of a structured
  requirements description

64
Requirements Validation Reviews

• Regular Reviews should be held while the
  requirements definition is being formulated
• Both client and contractor staff should be
  involved in reviews
• Reviews may be Formal (with completed documents)
  or Informal. Good communications between
  developers, customers and users can resolve
  problems at an early stage

65
During A Review, Each Requirement Should Be
Checked For Verifiability, Comprehensibility,
Traceability, Adaptability

1. Verifiability. Is the requirement realistically
   testable?
2. Comprehensibility. Is the requirement properly
   understood?
3. Traceability. Is the origin of the requirement
   clearly stated?
4. Adaptability. Can the requirement be changed
   without a large impact on other requirements?

66
Requirements Engineering2 Post-Analysis
Design Processes RequirementsManagement

67
Requirements Management

• Requirements Management is the process of
  managing changing requirements during the
  requirements engineering process and system
  development
• Requirements are inevitably incomplete and
  inconsistent
• New Requirements Emerge during the process as
  business needs change and a better understanding
  of the system is developed
• Different Viewpoints have different requirements
  and these are often contradictory

68
Requirements Change Examples

• The Priority of Requirements from Different
  Viewpoints changes during the development process
• System Customers may specify requirements from a
  business perspective that conflict with end-user
  requirements
• The Business and Technical Environment of the
  system changes during its development

69
Enduring Volatile Requirements

• Enduring Requirements. Stable requirements
  derived from the core activity of the customer
  organization. E.g. a hospital will always have
  doctors, nurses, etc. May be derived from domain
  models
• Volatile Requirements. Requirements which change
  during development or when the system is in use.
  In a hospital, requirements derived from
  health-care policy

70
Requirements Management Planning Managing Change
Of Requirements

• Requirements Identification
• How requirements are individually identified
• A Change Management Process
• The process followed when analyzing a
  requirements change
• Traceability Policies
• The amount of information about requirements
  relationships that is maintained
• CASE Tool Support
• The tool support required to help manage
  requirements change

71
Requirements Traceability

• Requirements Traceability is concerned with
  the relationships between requirements, their
  sources and the system design
• Source Traceability
• Links from requirements to stakeholders who
  proposed these requirements
• Requirements Traceability
• Links between dependent requirements
• Design Traceability
• Links from the requirements to the design

72
A Traceability MatrixAvailable In Some CASE Tools
73
Requirements Change Management3 Most Common
Change Stages

• Should apply to all proposed changes to the
  requirements
• The 3 Most Common Change Stages
• Problem Analysis. Discuss requirements problem
  and propose change
• Change Analysis Costing. Assess effects of
  change on other requirements
• Change Implementation. Modify requirements
  document and other documents to reflect change

74
Requirements Change Management Flow
75
Requirement ElicitationProblems

76
5 Problems Of Requirements Analysis

• Stakeholders dont know what they really want or
  need
• Stakeholders express requirements in their own
  terms
• Different stakeholders may have conflicting
  requirements
• Organizational and political factors may
  influence the system requirements
• The requirements change during the analysis
  process. New stakeholders may emerge and the
  business environment change

77
Software EngineeringCSCI 3342

• Dr. Thomas E. Hicks
• Computer Science DepartmentTrinity University
• Textbook Software EngineeringBy Roger Pressman
• Textbook Software EngineeringBy Ian Sommerville

Special Thanks To WCB/McGraw-Hill Addison
Wesley For Providing Graphics Of Some Of Text
Book Figures For Use In This Presentation.