Upload
bolah-roshan
View
189
Download
0
Tags:
Embed Size (px)
Citation preview
LECTURE 4
REQUIREMENTS ENGINEERING PROCESSES
CSE 2142 Software Engineering
Objectives
To describe the principal requirements engineering
activities and their relationships
To introduce techniques for requirements elicitation
and analysis
To describe requirements validation and the role of
requirements reviews
To discuss the role of requirements management in
support of other requirements engineering
processes
2
Challenges faced by Software Engineers3
Need for Requirements Engineering
Understanding the requirements of a problem is among
the most difficult tasks faced by a software engineer.
Just imagine a customer walking in your office and
saying “I know you think you understand what I said, but
what you don’t understand is what I said is not what I
mean”
Unfortunately these nightmares are very common in the
software industry and prove to be very costly as well.
Requirements Engineering provides a solid approach
for addressing these challenges
4
Requirements Engineering
Requirements Engineering is a process that involves all the activities required to create and maintain a system requirements document.
RE provides the appropriate mechanism for
understanding what the customer wants,
analyzing need,
assessing feasibility,
negotiating a reasonable solution,
specifying the solution unambiguously,
validating the specification,
managing the requirements as they are transformed into an operational system.
5
Requirements Engineering Activities
Feasibility
studies
Requirements
elicitation and
analysis
Requirements
validation
Requirements
management
Requirements
specificat io n
Requirements
validat ion
Requirementselicitat ion
System requirements
specificat io n an dmo deling
System
requirementselicitat ion
User requirementsspecificat io n
Userrequirements
elicitat ion
Busin ess requirementsspecificat io n
Prototyping
Feasibility
study
Reviews
System requirements
do cument
Spiral model of requirements engineering processes
6
Feasibility Study (1)
A feasibility study is a short, focused study which
aims to answer the following questions
Does the system contribute to the overall objectives of the
organisation?
Can the system be implemented using current technology
and within given cost and schedule constraints?
Can the system be integrated with other systems which
are already in place?
7
Feasibility Study (2)
Carrying out a feasibility study involves
information assessment phase identifies the information
which is required to answer the three questions set out
above
Information collection: users, managers, experts are
interviewed to obtain relevant information.
The input to the feasibility study is an outline description
of the system and how it will be used within an
organisation and the output should be a report which
recommends whether or not it is worth carrying on.
8
Requirements Elicitation and Analysis (1)
Concerned with learning and understanding the needs
of users and project sponsors with the ultimate aim of
communicating these needs to the system developers
Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints
May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
9
Requirements Elicitation and Analysis (2)
Stakeholders
Any person or group who will be affected by the
system, directly or indirectly
End-users
Managers
Engineers involved in development or maintenance
Domain experts
Trade union reps
10
Requirements Elicitation and Analysis
Process (1)
Requirements
discovery
Requirements
classification
and
organisation
Requirements
prioritisation
and
negotiation
Requirements
documentation
Requirementsclassificat ion and
organisat ion
Requirementspriorit izat ion and
nego tiat ion
Requirements
documentat ion
Requirements
discovery
11
Requirements Elicitation and Analysis
Process (2)
Requirements Discovery
The process of interacting with stakeholders in the
system to collect their requirements.
Domain requirements from stakeholders and
documentation are also discovered during this activity
Requirements Classification and organisation
This activity takes the unstructured collection of
requirements, groups related requirements and
organises them into coherent clusters
12
Requirements Elicitation and Analysis
Process (3)
Requirements Prioritisation and Negotiation
When it comes to selecting between different choices, it
becomes important to prioritize between the alternatives
Prioritization helps to identify the most valuable
requirements from this set by distinguishing the critical few
from the trivial many
Requirements Documentation
The requirements are documented and input into the next
round of the spiral.
Formal or informal requirements documents may be
produced
13
Question 1
Suggest who might be stakeholders in a university
student records system? Explain why it is almost
inevitable that the requirements of the different
stakeholders will conflict in some way
14
Question 2
Eliciting and understanding stakeholder
requirements is difficult for several reasons. Identify
the reasons underlying the difficulty.
15
Problems of Elicitation
Problems of scope boundary of system is ill-defined
unnecessary design information may be given
Problems of articulation users are aware of their needs but are unable to articulate them or afraid to articulate it
users may not be aware of their needs
Communication barriers user and analyst speak different languages
limitations of the communication language
Cognitive limitations
analysts have poor knowledge of problem domain
users have poor understanding of computer capabilities and limitations
Technical issues
requirements evolve over time
rapid software & hardware technology changes
16
Techniques for Requirements Elicitation
and Analysis (1)
Viewpoints A way of structuring the requirements to represent the perspectives of
different stakeholders
Interactor viewpoints People or other systems that interact directly with the system
Indirect viewpoints Stakeholders who do not use the system themselves but who influence the
requirements
Domain viewpoints Domain characteristics and constraints that influence the requirements
Interviewing The RE team puts questions to stakeholders about the system that they
use and the system to be developed
Closed interviews A pre-defined set of questions are answered
Open interviews No pre-defined agenda and a range of issues are explored with
stakeholders
17
Techniques for requirements elicitation
and analysis (2)
Scenarios
Real-life examples of how a system can be used
A description of the starting situation
A description of the normal flow of events
A description of what can go wrong
Information about other concurrent activities
A description of the state when the scenario finishes
Use-cases
Scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself
Ethnography
Observation of the day-to-day work and notes made of the actual task in which participants are involved
18
Viewpoint-Oriented Analysis
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 analyse system requirements
However, their perspectives are not completely
independent but usually overlap so that they have
common requirements.
The VORD (Viewpoint- Oriented Requirements Definition)
method designed in 1996-1998 by Sommerville &
Kotonya as a service oriented framework for
requirements elicitation & analysis
19
Types of viewpoint
Data sources or sinks
Viewpoints are responsible for producing or consuming data.
Analysis involves checking what data is produced and consumed and
validate assumptions.
Representation frameworks
Viewpoints represent particular types of system model. Each model
discovers different requirements.
Receivers of services
Viewpoints are external to the system and receive services from it.
Most suited to interactive systems
Viewpoints as data source/sinks & representation are
particularly valuable for discovering requirements conflict.
20
The VORD method
Viewpointidentification
Viewpointstructuring
Viewpointdocumenta tion
Viewpointsystem mapping
Viewpoint identification: Discover viewpoints which receive
system services and identify the services provided to each
viewpoint
Viewpoint structuring: Group related viewpoints into a
hierarchy.
Viewpoint documentation: Refine the description of the
identified viewpoints and services
Viewpoint-system mapping: Transform the analysis to an
object-oriented design
21
Autoteller viewpoints
The example used here is an auto-teller system which
provides some automated banking services which include
cash withdrawal, message passing ,ordering a statement
and transferring funds
The viewpoints are
Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department
22
Viewpoint identification
Querybalance
Gettransactions
Cashwithdrawal
Transactionlog
Machinesupplies
Cardreturning
Remotesoftwareupgrade
Ordercheques
Userinterface
Accountinformation
Messagelog
Softwaresize Invalid
userSystem cost Printe
r Security
Cardretention
Stolencard
Orderstatement
Remotediagnostics
ReliabilityUpdateaccount
Fundstransfer
Messagepassing
Cardvalidation
Customerdatabase
Manager
Accountholder
Foreigncustomer
Hardwaremaintenance
Bankteller
23
Viewpoint Structuring
EngineerManagerTellerForeign
customerAccountholder
Services
Order chequesSend messageTransaction listOrder statement
Transfer funds
Customer Bank staff
All VPs
Services
Query balanceWithdraw cash
24
Viewpoint Documentation
Customer
Account numberPINStart transactionSelect serviceCanceltransactionEnd transaction
Cash withdrawalBalance enquiry
Account holderForeigncustomer
Reference:
Attributes:
Events:
Services:
Sub-VPs:
Cash withdrawal
To improve customer serviceand reduce paperwork
Users choose this service bypressing the cash withdrawalbutton. They then enter theamount required. This isconfirmed and, if funds allow,the balance is delivered.
Customer
Deliver cash within 1 minuteof amount being confirmed
Filled in later
Reference:
Rationale:
Specification:
VPs:
Non-funct.requirements:
Provider:
25
Viewpoint Standard Forms
Viewpoint template Service template
Reference: T he viewpoint name. Reference: T he service name.Attributes: Attributes providing
viewpoint information.Rationale: Reason why the service is
provided.Events: A reference to a set of event
scenarios describing howthe system reacts toviewpoint events.
Specification: Reference to a list of servicespecifications. These maybe expressed in differentnotations.
Services A reference to a set ofservice descriptions.
Viewpoints: List of viewpoint namesreceiving the service.
Sub-VPs: T he names of sub-viewpoints.
Non-functionalrequirements:
Reference to a set of non -functional requirementswhich constrain the service.
Provider: Reference to a list of systemobjects which provide theservice.
26
Question 3
A software system is to be developed to managethe records of patients who enter a clinic fortreatment. The records include records of the allregular patient monitoring (temperature, bloodpressure, etc) treatments given, patient reactionsand so on. After treatment, the records of their stayare sent to the patient’s doctor who maintains theircomplete medical record. Identify the principalviewpoints which might be taken into account in thespecification of this system and organize these usinga viewpoint hierarchy diagram.
27
Question 4
For the “Library manager”, “Users” and “Systemmanagers” viewpoints identified in the library system,LIBSYS (Diagram in next slide), suggest three requirementsthat could be suggested by the stakeholders associatedwith that viewpoint.
The LIBSYS system has to include support forcataloguing new documents where the system catalogmay be distributed across several machines. Whatare likely to be the most important types of non-functional requirements associated with thecataloguing facilities?
28
Question 4 (cont’d)
Article
providersFinance
Library
manager
Library
staffUsers
InteractorIndirect
All VPs
Classificat ionsystem
UI
standards
Domain
ExternalStaffStudents CataloguersSystem
managers
Viewpoints in LIBSYS
29
30
Software Requirements Validation
Requirements validation is concerned with showing that the requirements actually define the system which the customer wants.
Validity checks : Does the requirement meet the objectives of the system.
Consistency checks : Requirements in the document should not conflict.
Completeness checks : The requirements document should includerequirements which define all functions and constraints intended by thesystem user.
Realism checks : Using knowledge of existing technology, the requirements
should be checked to ensure that they can actually be implemented.
Verifiability : requirements should be written such that a set of checks can
be designed to demonstrate that the delivered system meets that
requirement.
Requirements Validation Techniques
Reviews
Systematic manual analysis of the requirements
Verifiability
Is the requirement realistically testable?
Comprehensibility
Is the requirement properly understood?
Traceability
Is the origin of the requirement clearly stated?
Adaptability
Can the requirement be changed without a large impact on other requirements?
Prototyping
Using an executable model of the system to check requirements
Test-case generation
Developing tests for requirements to check testability
31
32
Requirements Management
Requirements management is the process of understanding and controlling changes to system requirements.
Different users have different requirements and priorities. It is oftendiscovered that priorities given to different users needs to bechanged.
System customers impose requirements because of organisationaland budgetary constraints. These may conflict with end-userrequirements.
The business and technical environment of the system changes andthese must be reflected in the system itself.
New hardware may be introduced,
business priorities may change with consequent changes in the system supportwhich is needed
new legislation and regulations may be introduced which must be implemented bythe system.
33
Requirements Classification
From an evolution perspective, requirements fall into two classes:
Enduring requirements - These are relatively stable requirements which derive from the core activity of the organisation and which relate directly to the domain of the system.
Volatile requirements - These are requirements which are likely to change during the system development or after the system has been put into operation.
Mutable Requirements - Requirements which change because of changes to the environment in which the organisation is operating.
Emergent - Requirements which emerge as the customer’s understanding of the system develops.
Consequential- Requirements which result from the introduction of the computer system.
Compatibility- Requirements which depend on the particular systems or business processes within an organisation.
34
Requirements Management Planning
Planning stage establishes the level of requirements management detail which is required. During the requirements management stage, you have to decide on:
Requirements identification: Each requirement must be uniquely identifiedthat it can be cross-referenced by other requirements and so that it may beus in traceability assessments.
A change management process: This is the set of activities which assessimpact and cost of changes.
Traceability policies: These policies define the relationships between requirements and between the requirements and the system design that should be recorded and how these records should be maintained. (Source, Requirements & Design traceability)
CASE tool support: Tools which may be used range from specialist requirements management system to spreadsheets and simple database systems.
35
Requirements Change Management
Requirements change management should be applied to all proposed changes to the requirements. There are three principal stages to a change management process:
Problem analysis and change specification
The process starts with an identified requirements problem . The problem is analysed to check that it is valid.
Change analysis and costing
The effect of the proposed change is using traceability information and general knowledge of the system The cost of making the change is estimated both in terms of the requirements document and, if appropriate, to the system design
Change implementation
The requirements document and, where necessary, the system design and implementation is modified.