Date post: | 19-Jul-2015 |
Category: |
Documents |
Upload: | ashenafi-workie |
View: | 33 times |
Download: | 1 times |
Sometimes called Requirements discovery.It certainly seems simple enough to ask the customer,the users, and others
What the objectives for the system or product areWhat is to be accomplishedHow the system or product fits into the needs ofthe business andFinally, how the system or product is to be used ona day-to-day basis.
But it isn’t simple—it’s very hard.
Interaction … match
Requirements Elicitation
Problem Statement What Problem Are We Trying to Solve?
The customer has only a vague idea of what is required
• The developer is willing to proceed with the “vagueidea” on the assumption that “we’ll fill in the details aswe go along”
• The customer keeps on changing requirements• Because of these changes, the developer may make
errors in specifications and development … and so itgoes …
Requirements comes from users and stakeholders who have demands and needs…
End-users, managers, engineers etc., Various problems typically arise:o Stakeholders don’t know what they really wanto Stakeholders express requirements in their own termso Different stakeholders may have conflicting
requirementso Organizational and political factors may influence the
system requirementso The requirements change during the analysis process.o New stakeholders may emerge.
Customers and other stake holders....
User strategies in providing needed information
SAMETHING strategy :- “Give me the same thing but in better format through the
computer” It indicates the user’s laziness, lack of knowledge, or both. The analyst has a little chance of succeeding because only
user can fully discover the real needs and problems.
KITCHEN SINK strategy: The user throws every thing into the requirement
definition. User provides an over statement of needs. It reflects user’s lack of experience.
User strategies in providing needed information
SMOKING strategy :- Sets up a smoke screen by requesting several features
when only one or two are needed. The extra requests are used as bargaining power. It reflects the users experience in knowing what he / she
wants.
Examples of valid software requirements
8
• Requirement #1:– The system shall maintain records of all payments
made to employees on accounts of salaries, bonuses,travel/daily allowances, medical allowances, etc
• Requirement #2:– The system shall allow user to search for an item by
title, author, or by international standard book
number.• Requirement #3:
– The system shall support at least 20 transactions per
second.
Types of Requirements
9
1. Functional Requirements
2. Non Functional Requirements[Quality Attributes ]
3. Pseudo Requirements
Functional Requirements
10
Describes system services or functions which areexpected by the users of the system.How the system should react to particular
inputs,How the system should behave in particular
situations.• Describing what the system does, or capture the
functionality of the systemFunctional requirements are the backbone of
the software Development. • It depends on the complexity of the software system.
11
• Requirement #1: – Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall use to access thatorder.
• Requirement #2:
– The user shall be able to search all of the initial setof databases for the given search id.
• Requirement #3:
– The system shall provide proper authentication forthe users to read documents in the document store.
Examples of Functional requirements
Non - Functional Requirements
12
NFRs are often called “Quality attributes”More critical than functional requirements.Represents 20% of the requirements of a systemHardest to elicit and specifyDefining good NFRs requires not only the involvement ofthe customer but the developers too
• All requirements must be verifiable– If not ‘verifiable’ then there is no indications that these
requirements have been satisfied. • Some must also be measured.
– Some may be directly measured; some measured via simulation.
If not met, the system may be useless.(They are not “second class” requirements.)
Product Requirements:
Specifies that the delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
Organizational Requirements:
are a consequence of organizational policies and procedures
e.g. process standards used, implementation requirements, etc.
External Requirements:
arises from factors which are external to the system and its development process
e.g. interoperability requirements, legislative requirements, etc.
14
What are Quality Attributes…?
15
•A set of constraints the system must satisfyand the standards which must be met by thedelivered system.
•Describes “how” the system achieves itsfunctional requirements
•Performance Reliability•Usability Efficiency•Maintainability•Portability Scalability•Security Integration etc.,
Performance – Response Time
16
Response time
particularly important for processes thatprocess a lot of data or use networks a greatdeal.
Requirements might stipulate < two secondresponse.
Might use a Timing bar indicating progress…
17
• The capability of the software to maintain thelevel of performance of the system when usedunder specified conditions
Reliability Criteria• Maturity: Capability of the software to avoid
failure as a result of faults in the software.• Fault tolerance: Capability of the software to
maintain a specified level of performance incases of software faults.
Reliability
18
The capability of the software to beunderstood, learned, used and liked bythe user, when used under specifiedconditions.
Usability Criteria• Understandability: capability of the software
product to enable the user to understand– whether the software is suitable, and– how it can be used for particular tasks and
conditions of use.
Usability
19
Usability Criteria
• Learnability: capability of the software productto enable the user to learn its application
• Operability: capability of the software productto enable the user to operate and control it.
• Likeability: capability of the software product tobe liked by the user.
Usability
20
The capability of the software toprovide the required performancerelative to the amount of resources used,under stated conditions
Resources may include other software products, hardware facilities, materials, (e.g. print paper, diskettes).
Efficiency
21
The capability of the software to be modified.
• Modifications may include– corrections,– improvements or adaptation of the
software to changes in environment,and in requirements and functionalspecifications.
Maintainability
22
Maintainability Criteria
• Changeability: The capability of the softwareproduct to enable a specified modification tobe implemented.
• Stability: The capability of the software tominimise unexpected effects frommodifications of the software
• Testability: The capability of the softwareproduct to enable modified software to bevalidated.
23
The capability of software to be transferred from one environment to another.
The environment may include organisational, hardware orsoftware environment.
Portability Criteria
Adaptability: The capability of the software to bemodified for different specified environments
Installability: The capability of the software to beinstalled in a specified environment.
Conformance: The capability of the software toadhere to standards or conventions relating toportability.
Portability
24
Security is a multi-faceted quality Difficult & specialized QA
Authentication: Applications can verify the identityof their users and other applications with which theycommunicate.Authorization: Authenticated users and applicationshave defined access rights to the resources of thesystem.Encryption: The messages sent to/from theapplication are encrypted.
Security
25
• Ease with which anapplication can beincorporated into abroader applicationcontext
• Use component in waysthat the designer did notoriginally anticipate
• Typically achieved by:– Programmatic APIs– Data integration
Integration
Pseudo Requirements • are requirements imposed by the client that
restrict the implementation of the system.– Typical pseudo requirements are the
implementation language and the platform onwhich the system is to be implemented.
• For life-critical developments, pseudo requirementsoften include process and documentationrequirements (e.g., the use of a formal specificationmethod, the complete release of all work products).
• Pseudo requirements have usually no direct effecton the users’ view of the system.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Levels of description In general, there are four levels of
description, which can uniformly bedescribed with use cases
1. Work division. This set of use cases describesthe work processes of the users that arerelevant to the system but the focus is ondefining the boundaries between the users andthe system.
2. Application-specific system functions. Thisset of use cases describes the functions that thesystem provides that are related to theapplication domain.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Levels of description3. Work-specific system functions. This set of use
cases describes the supporting functions of thesystem that are not directly related with theapplication domain. These include file managementfunctions, grouping functions, undo functions, andso on.
4. Dialog. This set of use cases describes theinteractions between the users and the user interfaceof the system. The focus is on designing resolvingcontrol flow and layout issues.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Completeness, Consistency, Clarity and Correctness
• Requirements are continuously validated withthe client and the user
• Validation is a critical step in the developmentprocess given both the client and developerdepend on the requirements specification.
• Requirements validation involves checkingthat the– specification is complete, consistent,
unambiguous, and correct
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Completeness:• It is complete if all the possible
scenarios through the system aredescribed, including exceptionalbehavior. ie. All aspects of the systemare represented in the requirementsmodel
• Consistency: The requirementsspecification is consistent if it does notcontradict itself.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
• Unambiguous: The SRS isunambiguous if exactly one system isdefined [ i.e.., it is not possible tointerpret the specification two or moredifferent ways.]
• Correct: A system is correct if itrepresents accurately the system thatthe client needs and that the developerintend to build
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Realism, Verifiability & Traceability
The most desirable properties ofrequirements specification.
• Realistic: The SRS is realistic if thesystem can be implemented withinconstraints.
• Verifiable: The SRS is verifiable if oncethe system is built, repeatable tests canbe designed to demonstrate that systemfulfills the requirements specification.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
• Traceable: A requirement specification istraceable if each requirement can be tracedthrough out the software development to itscorresponding system functions and viceversa.
• Traceability enables the tester to access thecoverage of the test case, to identify whichrequirements are tested and which are not.
• When evaluating changes, traceabilityenables the analyst & developers to identifyall components and system functions that thechange would impact
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
Greenfield EngineeringDevelopment starts from scratchNo prior system existsRequirements come from end users and clientsTriggered by user needs
Re-engineeringRe-design and/or re-implementation of an existingsystem using newer technologyTriggered by technology enabler
Interface EngineeringProvision of existing services in a new environmentTriggered by technology enabler or new marketneeds
Requirements Engineering Models