Recursive Nature of Requirements Development...© 2004 Kasse Initiatives, LLC version NDIA CMMI Conf...
Transcript of Recursive Nature of Requirements Development...© 2004 Kasse Initiatives, LLC version NDIA CMMI Conf...
SE Tutorial RE - 1version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsEngineeringEngineering
SE Tutorial RE - 2version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
What AreWhat AreRequirements?Requirements?
�Customer’s needs, expectations, andmeasures of effectiveness
�Items that are necessary, needed, ordemanded
�Implicit or explicit criteria that must, should, ormight be met
�Contain system and software information�Should not contain details regarding the
internal implementation of a solution�May be derived from other requirements
during analysis, operational concept andoperational scenarios development
SE Tutorial RE - 3version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
What AreWhat AreRequirements?Requirements? -- 22
�Description of the services the system is toprovide
�Description of how the system should behave�Description of the circumstances under which it
is required to operate�Application domain information�Constraints on the system’s operations�Specifications of a system property or attribute�Constraints on the development process of the
system
SE Tutorial RE - 4version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
What AreWhat AreRequirements?Requirements? -- 33
�Requirements might describe:�A user-level facility – the word processor must
include a spell checker and correction command
�A very general system property – the system mustensure that personal information is never madeavailable without authorization
�A specific constraint on the system – the sensormust be polled 10 times per second
SE Tutorial RE - 5version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
What AreWhat AreRequirements?Requirements? -- 44
�Requirements might describe: - continued�How to carry out some computation – the overall
mark is computed by adding the student’sexamination, project and coursework marks basedon the following formula ‘TotalMark = ExamMark +2* ProjectMark + 2/3 * CourseworkMark’
�A constraint on the development of the system –the system must be developed using the Adaprogramming language
SE Tutorial RE - 6version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
What AreWhat AreRequirements?Requirements? -- 55
�Requirements invariably contain a mixture of�Problem information
�Statements of system behavior
�Systems properties
�Design constraints
�Manufacturing constraints
�This can and normally does result in conflictsthat must be negotiated and resolved
SE Tutorial RE - 7version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Sources ofSources ofRequirementsRequirements
�Customer�Marketing�Surveys�Systems Engineering�Existing Systems, Specifications�Standards�Industry Studies�Academic Research
SE Tutorial RE - 8version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Sources ofSources ofRequirementsRequirements -- 22
�Prototyping
�Simulation
�Quality Assurance Group
�Configuration Management Group
SE Tutorial RE - 9version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types
�Business Requirements – Business requirements arethe reason for developing systems and software in thefirst place.�Business requirements are the essential activities of an
enterprise
�Business requirements are derived from business goalsor objectives
�The extent to which the system supports the businessrequirements and facilitates an organization in achievingthem is a key factor for the success of that system
�If the systems we build do not support the businessrequirements effectively and efficiently, they have noreason for being -- Businesses exist to make money!
SE Tutorial RE - 10version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 22
�System-Level Requirements – System-levelrequirements are foremost in importance,captures the vision of the customer, enablesdefining the scope of the system, and allowsestimating the cost and schedule required tobuild the system
�Functional Requirements – Functionalrequirements describe what the system mustdo. Functional requirements are sometimescalled behavioral or operational requirementsbecause they specify the inputs to the systemand the outputs from the system and thebehavioral relationships between them.
SE Tutorial RE - 11version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 33
�Design Requirements & Design Constraints –For many systems, design requirements /constraints appear at the beginning of thesystem formulation�New systems are often installed in environments
that already have other systems that constrain thedesign of the new system� Example – A design constraint may be that the
system to be developed must obtain itsinformation from an existing database
�For reasons of budget, schedule, or quality, anorganization may wish to reuse some or all existingsoftware systems in the implementation of a newsystem � This constrains both the requirements andthe design
SE Tutorial RE - 12version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 44
�If a system has to be approved by anexternal regulator, it may be necessary touse standard certified design that has beentested in other systems
�The system’s user interface shall beimplemented using a World-wide Webbrowser.
SE Tutorial RE - 13version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 55
�Performance Requirements – Performancerequirements define how well the functionalrequirements must perform. Performancerequirements must be defined in quantifiableterms and avoid such terms as:�Fast�Slow�Regular�Dependable�Reliable
�The system shall support at least 20transactions per second
SE Tutorial RE - 14version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 66
�Interface Requirements – Interfacerequirements represent the physical andfunctional relationships among systemelements and between system elements andthe system environment�Interface requirement may be specified by the
customer
�Interface requirements will come out of thearchitecture specification
�Interface requirements will be dictated by COTSproducts that are integrated into the system
SE Tutorial RE - 15version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 77
�Product Requirements – Productrequirements define the technical criteria thatmust, should, or might be met by the deliveredproduct
�Project Requirements – Project requirementsstipulate resources that will be madeavailable, and how different aspects of theproject will be carried out
�Process Requirements – Processrequirements indicate standards, procedures,methods, languages, ...
SE Tutorial RE - 16version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 88
�Qualification Requirements – Qualificationrequirements refer to the verification andvalidation of item performance in a specificapplication and results from design review,test data review, and configuration audits
�Environmental Requirements –Environmental requirements result from thephysical setting and social and culturalconditions of the system development effortand the setting in which the system will beused
SE Tutorial RE - 17version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsCategories or TypesCategories or Types -- 99
�Non-Functional Requirements – Non-functional requirements or Quality Factorsrefers to characteristics the system exhibitswhen placed in the operational environment.These quality factors are also referred to asthe “Illities” and include:�Maintainability�Expandability�Usability�Testability�Reliability�…………..
SE Tutorial RE - 18version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Customer orMarket Needs
System or ProductRequirements
HardwareRequirements
SoftwareRequirements
ServicesRequirements
Hierarchy ofHierarchy ofRequirementsRequirements
ProcessRequirements
PeopleRequirements
SE Tutorial RE - 19version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsLifecycleLifecycle
OrganizationPhase
ElicitationPhase
AnalysisPhase
PrototypePhase
Transform toSpecification
The User
RawRequirements
OrganizedRequirements
AnalyzedRequirements
Complete UserRequirements
SPECS
SE Tutorial RE - 20version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsEngineeringEngineering
�Discovering, documenting, baselining, andmaintaining a set of requirements for acomputer-based system
�Requirements “Engineering” implies thatsystematic and repeatable techniques shouldbe used to ensure that the systemrequirements are complete, consistent,relevant, etc.
SE Tutorial RE - 21version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsEngineeringEngineering -- 22
�Requirements Engineering topics include:�Elicitation�Analysis�Specification�Review�Traceability�Management
� Change Requests� Impact Analysis
�Verification�Validation
SE Tutorial RE - 22version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsDevelopmentDevelopment
SE Tutorial RE - 23version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Customer, Product, andCustomer, Product, andProduct ComponentProduct ComponentRequirementsRequirements
OperationalConcept &Scenarios
CustomerRequirements
Definition ofFunctionality
Product andProductComponentRequirements
DerivedRequirementsCustomer
End User
Co-workers &Management
Stakeholders
Marketing
RegulatoryAgencies
IndependentTest
QualityAssurance
SE Tutorial RE - 24version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Customer, Product, andCustomer, Product, andProduct ComponentProduct ComponentRequirementsRequirements -- 22
Processes
H/W, S/W,Mechanical,
Electrical,Engineering
Product
Require
ments
Alloca
tedto
Functions
Product andProductComponentRequirements
Services
People
Customer
End User
Co-workers &Management
Stakeholders
Marketing
RegulatoryAgencies
IndependentTest
QualityAssurance
SE Tutorial RE - 25version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Collecting andCollecting andTranslatingTranslatingStakeholders’ NeedsStakeholders’ Needs
�The needs, expectations, constraints,interfaces, operational concepts, and productconcepts of all stakeholders are collected,analyzed, harmonized, refined, elaboratedand translated into customer requirements
�Environmental, legal, regulatory and otherconstraints that may be external to thecustomer must also be applied when creatingand resolving the set of customerrequirements
SE Tutorial RE - 26version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Collecting andCollecting andCoordinatingCoordinatingStakeholders’ NeedsStakeholders’ Needs -- 22
�Stakeholders include:�Customers�End-users�Developers�Producers�Testers�Suppliers�Marketers�Maintainers�Safety Regulation Agencies�Managers
SE Tutorial RE - 27version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Elicitation TechniquesElicitation Techniques
�Examples of techniques to identify and elicitStakeholders’ needs include:�Dialogue�Scenario reviews�Technology demonstrations�Models�Simulations�Prototypes�Brainstorming�Observations of existing systems�Extractions from sources such as documents,
standards, and specifications
SE Tutorial RE - 28version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Generic RequirementsGeneric RequirementsElicitation ProcessElicitation Process
Businessgoals
Businessgoals
Problems tobe solved
Problems tobe solved
Systemconstraints
Systemconstraints
Organizationalstructure
Organizationalstructure
ExistingsystemsExistingsystems
Applicationdomain
Applicationdomain
StakeholderidentificationStakeholderidentification
Goalprioritization
Goalprioritization
Domainknowledge
filtering
Domainknowledge
filtering
Domainrequirements
Domainrequirements
StakeholderrequirementsStakeholder
requirements
Organizationalrequirements
Organizationalrequirements
Establish objectives Understand background Organize knowledge Collect requirements
Gerald Kotonya and Ian Sommerville,Requirements Engineering, John Wiley and Sons, 1998
SE Tutorial RE - 29version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
CustomerCustomerRequirementsRequirements
�Customer requirements make up a commonunderstanding of what will satisfy thestakeholders
�Customer requirements are analyzed toensure that they are complete, realizable, andverifiable, consistent, and testable�The analysis helps to determine what impact the
intended operational environment will have on theability to satisfy the stakeholder’s needs,expectations, constraints and interfaces
SE Tutorial RE - 30version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Product and ProductProduct and ProductComponentComponentRequirementsRequirements
�Product and product component requirementsdefine what the system is required to do andthe circumstances under which it is required tooperate
�Product and product component requirementsdefine the services that the product or productcomponent should provide and establishconstraints on how they will operate
�Product and product component requirementsinclude technical requirements and the criteriathat will be used to verify that the productssatisfy the requirements
SE Tutorial RE - 31version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Product and ProductProduct and ProductComponentComponentRequirementsRequirements -- 22
�The customer requirements are normallyexpressed in the customer’s terms and mayinclude non-technical descriptions
�Product requirements are the expression ofthose requirements in technical terms that canbe used for design decisions
�Customer requirements are analyzed inconjunction with the development of theoperational concept to derive a more detailedand precise set of requirements called“product and product componentrequirements”
SE Tutorial RE - 32version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Product and ProductProduct and ProductComponentComponentRequirementsRequirements -- 33
�The analysis of requirements may producederived requirements including:�Constraints�Implicit end-user issues�Factors introduced by the developer’s unique
business considerations, regulations, and laws�Requirements are allocated to functions,
product components, product performanceand design constraints including objects,people, and associated processes or services
SE Tutorial RE - 33version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Analyze RequirementsAnalyze Requirements
�During the iterative process of requirementsanalysis the following guidelines should becontinuously applied:�Analyze stakeholder needs, expectations,
constraints, and external interfaces to removeconflicts and to organize into related subjects
�Analyze requirements to ensure that they arecomplete, feasible, realizable and verifiable
�Identify key requirements that have a stronginfluence on cost, schedule, functionality, risk, orperformance
�Identify technical performance measures that willbe tracked during the development effort
SE Tutorial RE - 34version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
InterfaceInterfaceRequirementsRequirements
�Interfaces between functions must be definedand controlled as part of the product andproduct component integration
�As interface designs are defined, the designbecomes a requirement for products andproduct components that are affected by theinterface
SE Tutorial RE - 35version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Operational ConceptsOperational Conceptsand Scenariosand Scenarios
�Scenarios and Operational Concepts aredeveloped, analyzed, and reviewed to refineexisting requirements and discover newrequirements, needs, and constraints�Scenarios are normally sequences of events that
might occur in the use of the product
�Operational concepts depend on both the designsolution space and the scenarios
� define the interaction of the product, the enduser and the environment
� define the operational, maintenance, support,and disposal needs
SE Tutorial RE - 36version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Operational ConceptsOperational Conceptsand Scenariosand Scenarios -- 22
�Operational concepts and scenarios need tobe developed that include functionality,performance, maintenance, and disposal asappropriate
�The environment the product will operate in,including boundaries and constraints, needs tobe defined
SE Tutorial RE - 37version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Derived RequirementsDerived Requirements
�Derived requirements are analyzed, based onthe operational concept and scenarios, todevelop a more detailed and precise set ofproduct or product component requirements
�Analysis of derived requirements makes surethat they are necessary and sufficient to meetthe objectives of higher level requirements
�Determination must be made as to whichrequirements will be identified to tracktechnical progress against
SE Tutorial RE - 38version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
ValidatingValidatingRequirementsRequirements
�Customer requirements should be validatedearly in the development schedule to gainconfidence that the customer requirementsare capable of guiding a development thatresults in the customer’s operational needsbeing met
SE Tutorial RE - 39version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Spiral Model of theSpiral Model of theProduct RequirementsProduct RequirementsEngineering ProcessEngineering Process
START
Requirements elicitation
Requirements validationRequirements documentation
Requirements analysisand negotiation
Agreedrequirements
Draft Requirementsdocument
Requirementsdocument and
validation report
Informal statement ofrequirementsDecision point:
accept documentor re-enter spiral
Gerald Kotonya and Ian Sommerville,Requirements Engineering, John Wiley and Sons, 1998
SE Tutorial RE - 40version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Acceptance CriteriaAcceptance Criteria
�Acceptance Criteria should be part of the requirementscapture and specification process�Who will perform the acceptance testing
�What environment or portion of the user’s environmentmust be exercised to satisfy the acceptance criteria
�How much simulation is allowed to verify and validate therequirements
�What process will be followed if errors are found
�What classification of errors must be fixed before thesystem will be accepted
�What classification of errors may allow the system to beaccepted in the event that workarounds can be provided
SE Tutorial RE - 41version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsManagementManagement
SE Tutorial RE - 42version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RD
RM
TS
The Requirements Management andThe Requirements Management andRequirements Development PartnershipRequirements Development Partnership
SE Tutorial RE - 43version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Understanding ofUnderstanding ofRequirementsRequirements
�The project reviews the requirements to resolveissues before they are incorporated into the product
�Requirements and requirements change requests areanalyzed and reviewed to ensure that a compatible,shared understanding is reached on the meaning ofthe requirements:�Clearly and properly stated�Complete�Consistent with each other�Uniquely identifiable�Feasible and appropriate to implement�Able to be verified and validated through reviews and testing�Traceable
SE Tutorial RE - 44version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Changes toChanges toRequirementsRequirements
�Changes to the requirements must be controlled asthey evolve over the product lifecycle due to changingneeds and derived requirements
�All appropriate stakeholders review and agree on thechange requests to the requirements before they areapplied
�Approved changes to the requirements are tracked�A change history is maintained for each requirement
along with the rationale for the change� Initially captured and/or derived�After approved changes have been applied
�Applied changes to requirements are communicatedto all stakeholders in a timely manner
SE Tutorial RE - 45version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Changes toChanges toCommitments Based onCommitments Based onRequirements ChangesRequirements Changes
�Changes to commitments must be negotiatedwith all stakeholders
�Changes to commitments made external tothe organization should be reviewed by seniormanagement, as one of the stakeholders, toensure that commitment can be accomplishedalong with the other previously approvedcommitments
SE Tutorial RE - 46version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Impact Analysis forImpact Analysis forRequirements ChangeRequirements ChangeRequestsRequests
� Impact Analysis is made based on the requirementschange request:�Development Schedule�Release Schedule�Changes required to this system�Staffing�Components�Development and Target equipment�Risks�SCOPE�Costs�Changes required to other systems or interfaces within the
project�Other existing products or product lines
SE Tutorial RE - 47version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsTraceabilityTraceability
�Requirements cannot be managed effectivelywithout requirements traceability
�A requirement is traceable if:�You know the source of each requirement�Why the requirement exists�What requirements are related to it�How that requirement relates to other information
such as systems designs, implementations, anduser documentation
�Traceability information is used to find otherrequirements which might be affected byproposed changes
SE Tutorial RE - 48version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
RequirementsRequirementsTraceabilityTraceability -- 22
�All requirements and requirements changerequests throughout the product lifecycle arecaptured and placed under configurationmanagement
�Traceability is needed in conducting the impactanalysis of requirements change requests onthe project plans, activities, and work products
�A requirements traceability matrix is generatedand used for forward and backward tracing
SE Tutorial RE - 49version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
Consistency of LifeConsistency of Life--Cycle Work ProductsCycle Work Products
�The project plans, work products, andactivities are changed to be consistent withapproved changes made to the requirementsand must be:�Identified�Evaluated�Assessed for risk�Documented�Planned�Communicated�Tracked to completion
SE Tutorial RE - 50version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
SummarySummary
�Requirements development and requirementsmanagement contribute to productdevelopment�Requirements and analysis are essential to
producing high quality software and maintainingcontrol over product development
�Supports controls of requirements change requeststhroughout the development lifecycle
�Takes all stakeholders views into consideration
�Is an iterative and recursive process
SE Tutorial RE - 51version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC
SummarySummary -- 22
�Requirements are the foundation:�For the product (H/W and/or S/W)�For the planning�For acceptance by the customer�For defining quality expectations