Recursive Nature of Requirements Development...© 2004 Kasse Initiatives, LLC version NDIA CMMI Conf 3.5 SE Tutorial RE - 9 Requirements Categories or Types Business Requirements –

SE Tutorial RE - 1version NDIA CMMI Conf 3.5© 2004 Kasse Initiatives, LLC

RequirementsRequirementsEngineeringEngineering


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


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



�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



�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



�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


Sources ofSources ofRequirementsRequirements

�Customer�Marketing�Surveys�Systems Engineering�Existing Systems, Specifications�Standards�Industry Studies�Academic Research


Sources ofSources ofRequirementsRequirements -- 22

�Prototyping

�Simulation

�Quality Assurance Group

�Configuration Management Group


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!


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.



�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



�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.



�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



�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



�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, ...



�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



�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�…………..


Customer orMarket Needs

System or ProductRequirements

HardwareRequirements

SoftwareRequirements

ServicesRequirements

Hierarchy ofHierarchy ofRequirementsRequirements

ProcessRequirements

PeopleRequirements


RequirementsRequirementsLifecycleLifecycle

OrganizationPhase

ElicitationPhase

AnalysisPhase

PrototypePhase

Transform toSpecification

The User

RawRequirements

OrganizedRequirements

AnalyzedRequirements

Complete UserRequirements

SPECS


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.


RequirementsRequirementsEngineeringEngineering -- 22

�Requirements Engineering topics include:�Elicitation�Analysis�Specification�Review�Traceability�Management

� Change Requests� Impact Analysis

�Verification�Validation


RequirementsRequirementsDevelopmentDevelopment


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


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


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


Collecting andCollecting andCoordinatingCoordinatingStakeholders’ NeedsStakeholders’ Needs -- 22

�Stakeholders include:�Customers�End-users�Developers�Producers�Testers�Suppliers�Marketers�Maintainers�Safety Regulation Agencies�Managers


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


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


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


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


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”


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


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


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


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


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


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


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


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


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


RequirementsRequirementsManagementManagement


RD

RM

TS

The Requirements Management andThe Requirements Management andRequirements Development PartnershipRequirements Development Partnership


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


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


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


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


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


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


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


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


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

Documents

Recursive Nature of Requirements Development...© 2004 Kasse Initiatives, LLC version NDIA CMMI Conf 3.5 SE Tutorial RE - 9 Requirements Categories or Types Business Requirements –