eliciting requirements from our customers types of requirements notations and methods for capturing...
TRANSCRIPT
• Eliciting requirements from our customers• Types of requirements• Notations and methods for capturing
requirements• Reviewing requirements to ensure their
quality• Documenting requirements for use by the
design and test teams
Chapter four Capturing the Requirements
Case: Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).
The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4.
Is requirement analysis really important?
In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. 31% of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).
To understand why, Standish (1995) asked the survey
respondents to explain the causes of the failed projects.
The top factors were reported to be
1. incomplete requirements (13.1%)
2. lack of user involvement (12.4%)
3. lack of resources (10.6%)
4. unrealistic expectations (9.9%)
5. lack of executive support (9.3%)
6. changing requirements and specifications (8.7%)
7. lack of planning (8.1%)
8. system no longer needed (7.5%)
4.1 The Requirements ProcessRequirement: a feature of the system or a description of something
the system is capable of doing in order to fulfill the system’s purpose
Requirements Elicitation
Identify people, processes, and resources involved in system and document the relationships among them. Three kinds of requirements:– those that absolutely must be met– those that are highly desirable but not necessary– those that are possible but could be eliminated
Example: A Credit Card Billing System
List current charges, sum them, and request payment by a certain data
Separate the charges by purchase type to assist the purchaser in understanding buying patterns
Print the credits in black and the debits in red
Requirement Analysis
Each of the system’s requirements deals with objects or entities, the states they can be in , and the functions that are performed to change states or object characteristics.
Example: A System to Generate Paychecks
System Objects: an employee, a person who is paid by the company
System Limit: an employee may be paid no more than 40 hours a week
Relationships: employee X is supervised by employee Y if you can authorize a change to X’s salary.
What
Two Kinds of Requirements documents• Requirements definition: complete listing of what
the customer expects the system to do• Requirements specification: restates the definition in
technical terms so that the designer can start on the design
• Configuration management: supports direct correspondence between the two documents
Set of procedures that track
– requirements that define what the system should do
– design modules that are generated from requirements
– program code that implements the design
– tests that verify the functionality of the system
– documents that describe the system
Functional and non-functional requirements
• Functional requirements – Describe what the system should do
Functional requirements include:– What inputs the system should accept– What outputs the system should produce– What data the system should store that other
systems might use– What computations the system should
perform– The timing and synchronization of the above
•Non-functional requirements –Constraints that must be adhered to during development
All must be verifiable
Non-functional requirements include three main types
1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability
• Response time• Throughput• Resource usage• Reliability• Availability• Recovery from failure• Allowances for maintainability and enhancement
• Allowances for reusability
2. Categories constraining the environment and technology of the system.
• Platform
• Technology to be used
3. Categories constraining the project plan and development methods
• Development process (methodology) to be used
• Cost and delivery date – Often put in contract or project plan instead
4.2 Types of requirements
• Physical environment
• Interfaces
• Users and human factors
• Functionality
• Documentation
• Data
• Resources
• Security
• Quality assurance
4.3 Characteristics of requirements
• Are they correct?
• Are they consistent?
• Are they complete?
• Are they realistic?
• Does each describe something the customer needs?
• Are they verifiable?
• Are they traceable?
4.6 Prototyping requirements
• Throw-away prototypes• Evolutionary prototypes• Rapid prototypes
Example: A tool to track a user’s exercise each day
Requirement: user can enter the date for each exercise routine
Paper Prototyping
4.4 How to Express Requirements
Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way
Two types of analysis modeling are commonly used:
structured analysis
object-oriented analysis
Structured Analysis
•Analysis products must be highly maintainable, especially the software requirements specification.
•Problems of size must be dealt with using an effective method of partitioning.
•Graphics should be used whenever possible.
•Find something to help with requirements partitioning and document the partitioning before specification.
•Devise tools that describe logic and policy better than narrative text.
Analysis Model Elements
Objectives Describe what the customer requires
Establish a basis for the creation of a software design
Define a set of requirement that can be validated once the software is built
ERD DFD
STD
DDDescription of data objects
process specification
control specification
•Data Dictionary(DD) - contains the descriptions of all data objects consumed or produced by the software
•Entity Relationship Diagram (ERD) - depicts relationships between data objects
•Data Flow Diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)
•State Transition Diagram (STD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)
Data Modeling
Data Modeling Elements
•Data object - any person, organization, device, or software product that produces or consumes information
•Attributes - name a data object instance, describe its characteristics, or make reference to another data object
•Relationships - indicate the manner in which data objects are connected to one another
LJL
BLF
White
Blue
Coupe
Sedan
XZ765…
Q12A45…
750iL
Taurus
BMW
Ford
ownerColor Type ID#ModelManufacturer
instance
Identifier
Attributes
Data object Attributes
Name
Address
Age
Driver's license ID
Manufacturer
Model
ID
Color
Relationships
possession
Cardinality and Modality
•Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object
1: 1
1: N
M:N
•Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship
Customer Mend action
Cardinality: one customer waits for mend actio
n
Modality: must a mend action must correspond to a customer
Cardinality: maybe have many mend actions
Modality: optional exist the situation of needless mend
action
Entity-Relation Diagram (ERD)
Entity Student Instructor Class
Enrolled in TeachRelations
single entity many entities
must optional
Attributes Name ID#
…………
Instructor Student
Enrolled inTeach
Class
I D # I D #
Name Name
Sex Sex
Title
Instructor ID
Class ID
Grade
Student ID
Class ID
CreditI D #Subject
Provides representations of all data objects.
Functional Modeling and Information Flow
• Data Flow Diagram-Shows the relationships of external entities, process or transforms, data items, and data stores
•DFD cannot show procedural detail (e.g. conditionals or loops) only the flow of data through the software
input Data storage
function Data flow
output
physician patientSee doctor system
Bill
medication
Medical experience and knowledge
FAB
AV
W
X
Y
Z z1 z2
z3
Bf1f2
f3
f4 f5
f6
f7
X
Y
x1 x2
y1 y2Z
f4.1
f4.2
f4.3
f4.4
f4.5
Refinement from one DFD level to the next
Behavioral Modeling
•State transition diagrams represent the system states and events that trigger state transitions
•STD indicates actions (e.g. process activation) taken as a consequence of a particular event
•A state is any observable mode of behavior
statestate
new statenew state
event causing transitionaction that occurs
Data Dictionary Contents
Name: Aliases: Where used: How used: Content description : Supplementary information
the primary name of the composite data item other names for the data item data transforms (processes) that use the composite data item the role of the data item (input, output, temporary storage, etc. a notation for representing content (presented on next slide) specific information about data types, pre-set values (if known)
The Notation of DD’s Content Description
Data Structure mark sense
= make up of
Sequence + add
Choose [ | ] or
Iteration {}n n times’ repeat
( ) optional data
** limitative note
telephone numberintegrated
office phone system
Name: Aliases: Where/How used: Description: Format:
telephone number phone number, number read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input) telephone no. = [ local extension | outside no. | 0 ] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator*
Build the requirements dictionary:
alphanumeric data
system output
4.7 Requirements documentation
• Requirements definition document: what the customer wants– general purpose– background and objectives of system– description of customer-suggested approach– detailed characteristics– operational environment
• Requirements specification document: what the designers need to know
Example4..1.3.1 INITIATE TRACK ON IMAGE. Logical processing shall be done toINITIATE TRACK ON IMAGE. This shall have as input HANDOVER DATA.This shall have as output HOIQ, STATE DATA, and IMAGE ID. This logicalprocessing shall, when appropriate, identify a new instance of IMAGE. Thislogical processing, when appropriate, shall identify the type of entity instance asbeing IMAGE ON TRACK. NOTE: A request for pulses is made by entering aformal record into the HOIQ which feeds the pulse-send procedures.
ALPHA: I NI TI ATE_TRACK_ON_I MAGE.I NPUTS: HANDOVER_DATA.OUTPUTS: HOI Q. STATE_DATA, I MAGE_I D.CREATES: I MAGE.SETS: I MAGE_ON TRACK.DESCRI PTI ON: “( 4. 1. 3. 1) A REQUEST FOR PULSE I S MADE BY
ENTERI NG A FORMAL RECORD REQUEST I NTO THE HOI Q WHI CH FEEDS THE PULSE SENDI NG PROCEDURES. ”
4.8 Participants in requirements process
• Contract monitors
• Customers and users
• Business managers
• Designers
• Testers
• Requirements analysts
Developers don‘t understand operational needs.How developers see users How users see developers
Users don‘t know what they want.Users can‘t articulate what they want. Developers place too much emphasis on
technicalities.Users have too many needs that are politically
motivated.Developers try to tell us how to do our jobs.
Users want everything right now. Developers can‘t translate clearly-stated needs into a successful system
Users can‘t prioritize needs. Developers say no all the time.Users refuse to take responsibility for the system.
Developers are always over budget.
Users are unable to provide a usable statement of needs
Developers are always late.
Users are not committed to system development projects.
Developers ask users for time and effort, even to the detriment of the users?important primary duties.
Users are unwilling to compromise. Developers set unrealistic standards for requirements definition.
Users can‘t remain on schedule. Developers are unable to respond quickly to legitimately changing needs
4.9 Requirements Validation
The purposes of requirements analysis:
• Provide a way for customers and developers to agree on what it is the system is to do
• Provide guidelines for the system designers
Requirements Validation: the process of determining that the specification is consistent with the requirements definition.
Two steps:
•Make sure that each specification can be traced to a requirement in the definition document
•Check the definition to see each requirement is traceable to the specification
Table 4.6. Requirements validation techniques.
Manual techniques ReadingManual cross-referencingInterviewsReviewsChecklistsManual models to check functions and relationshipsScenariosMathematical proofs
Automated techniques Automated cross-referencingAutomated models to enact functionsPrototypes
Requirements review
• Review goals and objections of system.• Compare requirements with goals and objectives.• Describe operational environment.
Examine– interfaces– information flow– functions
Check for omissions, incompleteness, inconsistency.• Document risk.• Discuss how system will be tested.
4.10 Measuring Requirements
4.11Choosing a specification technique
• Applicability• Implementability• Testability/simulation• Checkability• Maintainability• Modularity• Level of abstraction/expressibil
ity• Soundness
• Verifiability• Run-time safety• Tools maturity• Looseness• Learning curve• Technique maturity• Data modeling• Discipline
Information system example
Adver t i si ng Campai gn = *Ent i t y. Recor ds t he condi t i ons and ai msf or a campai gn t o adver t i se a pr oduct . *Campai gn Number + Campai gn St ar t Dat e + Campai gn End Dat e
+ Tar get Audi ence + Tar get Rat i ng Per cent age+ Campai gn Pr edi ct ed Rat i ng + Campai gn Budget Tot al+ Pi ccadi l l y Budget Amount + Campai gn Dur at i on+ {Requi r ed Spot Dur at i on}*Wor k necessar y t o r emove or j ust i f y t he r epeat i ng gr oup. *
Tar get Audi ence = *Dat a el ement . The audi ence at whi ch a campai gni s ai med. See Audi ence Type f or val ues. *
Audi ence Type = *Dat a el ement . Used t o cl assi f y r at i ngs fi gur es. *[Homes | Homemakers | Adults | Men | Women | Children]
Advertising agencies
Unavailable campaign
Predicted rating
Episode
Breakchart day Commercial break
Ratecard segment
Spot rate
Ratecard period
Advertising campaign
Advertising agency
Product
Campaign requirement
Suggested campaign
Unavailable campaign
Suitable time
Priced time
Commercial spot
Select suitable time
Price the time
Create suggested campaign