The Software Lifecycle

blurtedweeweeΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

87 εμφανίσεις

The Software Lifecycle

waterfall model

Requirements Specification


High-level description of what a system should
do


Must be detailed enough to distinguish between
the “right” and the “wrong” system


Capture the
what

not the
how


The specification process must involve all
stakeholders


Customers


Engineers


Regulatory agencies


Users
source:
heimdahl

Importance of Requirements


The Engineering Argument


Engineering is about developing solutions to problems


A good solution can only be developed if the engineers
have a solid understanding of the problem


The Economic Argument


Errors cost more to correct the longer they go
undetected


Cost of correcting requirements errors is (at least) 100
times more in the maintenance phase than in the
requirements phase


The Empirical Argument


Failure to understand and manage requirements is the
biggest single cause of cost and schedule over-runs
source:
heimdahl

Why Are Requirements Important?



Top factors that caused project to fail


Incomplete requirements (13.1%)


Lack of user involvement (12.4%)


Unrealistic expectations (9.9%)


Lack of executive support (9.3%)


Changing requirements and specifications (8.7%)


Lack of planning (8.1%)


System no longer needed (7.5%)


Some part of the requirements process is
involved in almost all of these causes


Requirements error can be expensive if not
detected early
source:
pfleeger

Cost Overruns vs. Requirements Effort
% Cost
Overrun
% Effort on Project Scope and
Requirements Engineering
credit:
werner

gruhl
, NASA
Example of an Unintended Feature



From the News: London underground train
leaves station without driver!


A passenger door was stuck and did not close


The driver left his train to close the passenger
door


He left the driver door open


He relied on the specification that said the train
does not move if at least one door is open


When he shut the passenger door, the train left
the station without him. Why?


The driver door was not treated as a door in
the source code!
source:
bruegge

How Users and Developers View Each Other


How developers see
users


users don’t know what
they want


users can’t articulate
what they want


users are unable to
provide a usable
statement of needs


How users see develop-
ers



developers don’t
understand operational
needs


developers can’t translate
clearly stated needs into a
successful system


developers set unrealistic
standards for
requirements definition
source:
pfleeger

How Users and Developers View Each Other


How developers see
users


users have too many
needs that are politically
motivated


users want everything
right now


users can’t remain on
schedule


users can’t prioritize
needs


How users see develop-
ers



developers place too
much emphasis on
technicalities


developers are always
late


developers can’t
respond quickly to
legitimately changing
needs


developers are always
over budget
source:
pfleeger

How Users and Developers View Each Other


How developers see
users


users are unwilling to
compromise


users refuse to take
responsibility for the
system


users are not committed
to the development
process


How users see develop-
ers



developers say “no” all of
the time


developers try to tell us
how to do our jobs


developers ask users for
time and effort, even to
the detriment of the
users’ important primary
duties

source:
pfleeger

Even Wally Knows
source:
heimdahl

The Requirement


It may range from a high-level abstract
statement of a service or of a system constraint
to a detailed mathematical functional
specification


This is inevitable as requirements may serve a
dual function


May be the basis for a bid for a contract


Therefore must be open to interpretation


May be the basis for the contract itself


Therefore must be defined in detail


Both these statements may be called
requirements
source:
heimdahl

Requirements Engineering


The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
developed
source:
heimdahl

The Software Requirements Specification


The SRS writer shall address the following


Functionality


What is the software supposed to do?


External Interfaces


How does the software interact with people, the system's
hardware, other hardware, and other software?


Performance


What is the speed, availability, response time, recovery
time of various software functions, etc.?


Attributes


What are the portability, maintainability, security, etc.
considerations?
IEEE Std 830-1998
The Software Requirements Specification


The SRS writer shall address the following


Design constraints imposed on an implementation


Are there any required standards in effect, implementation
language, policies for database integrity, resource limits,
operating environment, etc.?
IEEE Std 830-1998
SRS Should
not
Include


Project development plans (cost, staffing, schedules,
methods, tools, etc.)


Lifetime of SRS is until the end of the operational life of
the product


Lifetime of development plans is much shorter


Product assurance plans (CM, V&V, test, QA, etc.)


Different audiences


Different timelines


Design


Requirements and design have different audiences


Analysis and design are different areas of expertise
(requirements experts should not do design)


Except where the application domain constrains the design,
e.g., limited communications bandwidth or security
concerns
source:
heimdahl

Types of Requirements



Functional requirement
: describes required
behavior
in terms of required activities


Nonfunctional
requirement
: describes some
quality characteristic that the software must
posses


Design constraint
: a design decision such as
choice of platform or interface components


Process constraint
: a restriction on the
techniques or resources that can be used to
build the system
source:
pfleeger

Functional Requirement


Functionality


what will the system do?


when will the system do it?


are there several modes of operation?


what kinds of computations or data transformations
must be performed?


what are the appropriate reactions to possible
stimuli?
source:
pfleeger

Functional Requirement


Data


for both input and output, what should be the format
of the data?


must any data be retained for any period of time?
source:
pfleeger

Nonfunctional Requirements


Performance


are there constraints on execution speed, response
time, or throughput?


what efficiency measures will apply to resource
usage and response time?


how much data will flow through the system?


how often will data be received and sent?
source:
pfleeger

Nonfunctional Requirements


Usability and human factors


what kind of training will be required for each type
of user?


how easy should it be for a user to understand and
use the system?


how difficult should it be for a user to misuse the
system?
source:
pfleeger

Nonfunctional Requirements


Security


must access to the system or information be
controlled?


should each user’s data be isolated from the data of
other users?


should user programs be isolated from other
programs and from the operating system?


should precautions be taken against theft or
vandalism?
source:
pfleeger

Nonfunctional Requirements


Reliability and availability


must the system detect and isolate faults?


what is the prescribed mean time between failures?


is there a maximum time allowed for restarting the
system after failure?


how often will the system be backed up?


must backup copies be stored at a different location?


should precautions be taken against fire or water
damage?
source:
pfleeger

Nonfunctional Requirements


Maintainability


will maintenance merely correct errors, or will it
also include improving the system?


when and in what ways might the system be changed
in the future?


how easy should it be to add features to the system?


how easy should it be to port the system from one
platform (computer, operating system) to another?
source:
pfleeger

Nonfunctional Requirements


Precision and accuracy


how accurate must data calculations be?


to what degree of precision must calculations be
made?


Time to delivery/cost


is there a prescribed timetable for development?


is there a limit on the amount of money to be spent
on development or on hardware or software?
source:
pfleeger

Design Constraints


Physical environment


where is the equipment to be located?


is there one location or several?


are there any environmental restrictions, such as
temperature, humidity, or magnetic interference?


are there any constraints on the size of the system?


are there any constraints on power, heating, or air
conditioning?


are there constraints on the programming language
because of existing software components?
source:
pfleeger

Design Constraints


Interfaces


is input coming from one or more other systems?


is output going to one or more other systems?


is there a prescribed way in which input/output data
must be formatted?


is there a prescribed medium that the data must
use?


Users


who will use the system?


will there be several types of users?


what is the skill level of each user?
source:
pfleeger

Process Constraints


Resources


what materials, personnel, or other resources are
needed to build the system?


what skills must the developers have?


Documentation


how much documentation is required?


should it be online, in book format, or both?


to what audience should each type of documentation
be addressed?
source:
pfleeger

Non-Functional Requirements Examples


Product requirement


It shall be possible for all necessary communication
between the ATM and the user to be expressed in the
standard ASCII character set.


Organizational requirement


The system development process and deliverable
documents shall conform to the process and
deliverables defined in XYZCo-SP-STAN-95.


External requirement


The system shall use a file format readable by MS-
Word 6.0 and 2000.
source:
heimdahl

Making Requirements Testable



Fit criteria form objective standards for judging
whether a proposed solution satisfies the
requirements


It is easy to set fit criteria for
quantifyable

requirements


It is hard for subjective quality requirements


Three ways to help make requirements testable


Specify a
quantitave
description for each adverb and
adjective


Replace pronouns with specific names of entities


Make sure that every noun is defined in
exaclty
one
place in the requirements documents
source:
pfleeger

Making Requirements Testable



Poor requirement for testing


Good requirement for testing
Water quality information must be accessible
immediately.
Water quality records must be retrieved within 5
seconds of a request.
source:
pfleeger