11

Requirements Requirements Analysis IAnalysis I

FromFrom

Book: Use Cases – Requirements in Context Second Book: Use Cases – Requirements in Context Second EditionEdition

Book: RUP – Chapter 9 – The Requirements DisciplineBook: RUP – Chapter 9 – The Requirements Discipline

Article: “The Role of Requirements Traceability in Article: “The Role of Requirements Traceability in System Development” – by Dean Leffingwell, System Development” – by Dean Leffingwell, copyright: Rational Software, 2002. hcopyright: Rational Software, 2002. http://www.therationaledge.com/content/sep_02/m_requirementsTraceability_dl/.jsp

22/37/37

Traditional ActivitiesTraditional Activities Typical development activities include:Typical development activities include:

– business modelingbusiness modeling– requirements gathering, requirements gathering, – analysis and design, analysis and design, – construction, construction, – testing, testing, – deployment and deployment and – maintenance.maintenance.

Frequently given lip service:Frequently given lip service:– Business modelingBusiness modeling– Requirements gatheringRequirements gathering– TestingTesting– DeploymentDeployment– MaintenanceMaintenance

33/37/37

Landscape of RequirementsLandscape of Requirements

Perception changing from only emphasizing big three:– Analysis, design, and construction

Increasing Realization of criticality of – Business Modeling and – Requirements - their verification and traceability.

More projects fail due to poor requirements specification and poor requirements management than for any other reasons.– that is, Changing Requirements and their management

and scope creep – usually ‘not formal’ but ever-present!

44/37/37

Requirements: Difficult to Requirements: Difficult to CaptureCapture

Sometimes done by BA (Business Analysts); sometimes done by System Analysts - But not always!

Sometimes (especially BAs)they have difficulty in mapping abstract “needs” to “features” understandable by developers…

Sometimes done by developers with much input from BAs (know the environment) and SAs and others.

Typically developers have limited knowledge of application domain.

Developers often have difficulty communicating with Business Analysts and others.

55/37/37

Landscape of RequirementsLandscape of Requirements Often developers don’t like to spend lots of time here

(we should, but we don’t) “Takes too long” Developers like to plod on (often operating under false

assumptions). In fairness:

– Requirements can take form of huge requirements lists– Horribly boring– Difficult to discern critical needs from desires.– Requirements may sometimes be dictated by a single person

(depending on size of application, this may not be good! – You will get ‘that’ person’s views and biases.

66/37/37

Goals of Requirements Goals of Requirements DisciplineDiscipline

To establish and maintain agreement with To establish and maintain agreement with the customers and other stakeholders on the customers and other stakeholders on whatwhat the system should do and why. the system should do and why.

To provide system-developers with a better To provide system-developers with a better understanding of the understanding of the system requirementssystem requirements

To define To define boundariesboundaries (delimit) of the (delimit) of the systemsystem

To provide a To provide a basis for planningbasis for planning the the technical contents of iterationstechnical contents of iterations

To provide a To provide a basis for estimating cost basis for estimating cost and timeand time to develop the system to develop the system

7/37

Functional and Non-Functional Requirements Functional requirements are what the users

need for the system to work. “Need to add, change and delete transactions” “Need to generate ‘this’ report and ‘that’ report…” System must be able to do ‘these’ things. System must be learnable; have utility; be usable!!

Non-functional requirements (Quality attributes) Items like performance, scalability, usability,

supportability, reliability, security, backup/recovery… Normally documented: Supplementary Specifications Vitally important (sometimes hidden); global

88/37/37

Functional RequirementsFunctional Requirements Merely something that the computer application

does for its users. A value or feature! Functional requirements are used to express the

behavior of a system by specifying both the input and output conditions that are expected to result.

Sum of requirements => scope of application– Add requirements? Scope increases…– Scope creep! (Discuss…)

Requirements indicate specific system responses to user inputs (behaviors; interactions).

9/37

Non-Functional Requirements

Non-functional ‘quality’ attributes of system.– Usability –

Human factors – aesthetics, ease of use, learning; consistency in the user interface; training, …

– Reliability Addresses the frequency and severity of failure; recoverability…

– Performance Transaction rates/speeds, availability, response time, recovery time

– Supportability Testability, maintainability, …

– Security Application is protected from unauthorized access. (or parts of it)

Not tied (normally) to specific functions – but vital! Often thread many requirements.

1010/37/37

Requirements ArtifactsRequirements Artifacts Inputs: From Business Modeling

– Business Models (Business Vision document, Business Use Case; Business Object Models; Domain Model, Risks Lists, Business Rules, etc.)

Outputs: Requirements Artifacts – Software Requirements Specification (SRS)- Produced:– Product Vision Document – (application to be developed)

Contains Needs and Features.

– Functional Specifications as captured in the Use Case Model (Use Case Diagrams and Use Case Specs)

– Supplementary Specifications (local conventions – ways or procedures for doing things) - Non-functional requirements, and a number of other things – Schedule, ROI, Anticipated conversions, etc.

1111/37/37

The Pecking OrderThe Pecking Order So HOW do we elicit and capture (model) the

Requirements? Let’s go backwards:– Requirements (captured in Use Cases

and in Supplementary Specs) are identified to support a given Feature / Features captured as Stakeholder Needs in the Vision document for the Application.

Thus we have a mapping: Needs Features Use Cases / Supp

Specs

1212/37/37

1313/37/37

TraceabilityTraceabilityWe have a ‘traceability relationships.’We have a ‘traceability relationships.’–NeedsNeeds – –

Captured Captured NeedsNeeds (desires) obtained from Stakeholders (desires) obtained from Stakeholders must must TRACETRACE toto specific specific FeaturesFeatures (functional (functional requirements) which map (requirements) which map (tracetrace toto) to specific ) to specific requirementsrequirements as captured via ‘stories’ in as captured via ‘stories’ in Use Cases and Use Cases and the Supplementary Specifications.the Supplementary Specifications.

–A A NeedNeed may be ‘fulfilled by’ or is ‘part of’ or some may be ‘fulfilled by’ or is ‘part of’ or some kind of kind of featurefeature, etc., etc.

So, such So, such traceability relationshipstraceability relationships (much in the (much in the literature!) are literature!) are essentialessential to developing quality to developing quality applications and to assure stakeholder needs are indeed applications and to assure stakeholder needs are indeed accommodated in the resulting application.accommodated in the resulting application.

1414/37/37

Product Vision DocumentProduct Vision Document

Complete visionComplete vision of software under development of software under development Basis for funding authority and development Basis for funding authority and development

organization.organization. Written from cWritten from customer’sustomer’s perspective perspective

focusing on essential focusing on essential featuresfeatures and and qualityquality.. Includes ‘Includes ‘whatwhat’ will be included’ will be included Captures User Captures User NeedsNeeds and and FeaturesFeatures.. Specifies operations and characteristicsSpecifies operations and characteristics

– Volumes, response times, user profiles, interfaces with Volumes, response times, user profiles, interfaces with other systems.other systems.

Is the Is the Contractual basisContractual basis for the for the requirements visible to the stakeholders.requirements visible to the stakeholders.

1515/37/37

Functional SpecificationsFunctional Specifications captured in the Use Case Model / captured in the Use Case Model /

SpecificationSpecification Concentrates on the Concentrates on the functionalityfunctionality of system of system

Can serve as a contract among the customer, users, Can serve as a contract among the customer, users, and developersand developers

Consists of Use Case Consists of Use Case DiagramsDiagrams, , Use Case Use Case SpecificationsSpecifications (or use case narratives or descriptions) (or use case narratives or descriptions) and and ActorsActors

Use Cases serve as the Use Cases serve as the unifying threadunifying thread throughout the software lifecycle and throughout the software lifecycle and drivedrive analysis, analysis, design, implementation, testing, iteration planning, design, implementation, testing, iteration planning, software architecture, interface prototype software architecture, interface prototype development, and a development, and a hosthost of additional activities. ( of additional activities. (This This is a is a very important concept)very important concept)

1616/37/37

Supplementary Supplementary SpecificationsSpecifications

Normally a text document citing the ‘-abilities’ Normally a text document citing the ‘-abilities’ required, such asrequired, such as– Usability, Scalability, Maintainability, Efficiency, Usability, Scalability, Maintainability, Efficiency,

Reliability, Portability, etc. Reliability, Portability, etc. – Sometimes considered as Sometimes considered as constraintsconstraints on designon design! !

Good!!Good!!

May also include:May also include:– Glossary (from Domain Analysis) - extendedGlossary (from Domain Analysis) - extended– Domain Model (from Domain Analysis) – Domain Model (from Domain Analysis) – extendedextended / /

modifiedmodified– Storyboards (serve as basis for User Interface Storyboards (serve as basis for User Interface

Prototypes) – developed from Use Cases.Prototypes) – developed from Use Cases. Typically developed ‘in parallel’ with other requirements Typically developed ‘in parallel’ with other requirements

activitiesactivities

1717/37/37

Stakeholder NeedsStakeholder Needs

Stakeholder needs may arise from a Stakeholder needs may arise from a variety of sources, as explained in the variety of sources, as explained in the past.past.

Questionnaires, Interviews, Quarterly Questionnaires, Interviews, Quarterly Reports, Newsletters, Web pages, Annual Reports, Newsletters, Web pages, Annual Reports; Stockholder reports; Consortia Reports; Stockholder reports; Consortia of corporations, etc. are but a few.of corporations, etc. are but a few.

The list is rather endless.The list is rather endless. Let’s look at a few.Let’s look at a few.

1818/37/37

Standard Approaches (1 of 5) Standard Approaches (1 of 5)

User InterviewsUser Interviews:: Try to learn Try to learn – how users do their jobs now, how users do their jobs now, – how they expect their jobs to change, and how they expect their jobs to change, and – typical problems they encounter now.typical problems they encounter now.

Interview different people at different levels – note biases Interview different people at different levels – note biases / conflict/ conflict

We get ‘their’ perspectiveWe get ‘their’ perspective Customer, end-user, client, etc…Customer, end-user, client, etc…

User QuestionnairesUser Questionnaires– lots of pros/cons. lots of pros/cons. – Many ‘types’ and ways to administer… Lots of philosophies on Many ‘types’ and ways to administer… Lots of philosophies on

creating types of questions – open-ended, closed, etc., and creating types of questions – open-ended, closed, etc., and methods to evaluate the responses (if any…)methods to evaluate the responses (if any…)

1919/37/37

Standard Approaches (2 of Standard Approaches (2 of 5)5)

Joint Requirements Planning Sessions (JRPS)Joint Requirements Planning Sessions (JRPS) – Conduct all interviews at same time in same room.Conduct all interviews at same time in same room.– All key people brought together.All key people brought together.– Have facilitator, scribe, projectors, and support Have facilitator, scribe, projectors, and support

software…software…– Focus is on Focus is on WHATs ofWHATs of the system the system – Have representatives of Have representatives of all key stakeholdersall key stakeholders– High-level topics (in JRP) are first: critical success factors, High-level topics (in JRP) are first: critical success factors,

strategic opportunities, vision, risks, business rules, …strategic opportunities, vision, risks, business rules, …– Functional/non-functional requirements identified, Functional/non-functional requirements identified,

documented, and prioritized together!!documented, and prioritized together!! OWNERSHIP!!OWNERSHIP!!– Often conducted off-site.Often conducted off-site.– Artifact: the document produced: a list of requirements. Artifact: the document produced: a list of requirements.

(List? Ech!)(List? Ech!)

2020/37/37

Standard Approaches (3 of Standard Approaches (3 of 5) 5)

Requirements Lists – Functional Specs– Problems with Requirements Lists– Most people detest requirement lists!

Replace with Use Case Specifications, Use Case diagrams, and business rules.

– Not always replaceable: Requirements lists are sometimes used at very early stages for stakeholders and clearly differentiating sub-requirements (alternatives, exceptions, …

2121/37/37

Standard Approaches (4 of 5)Standard Approaches (4 of 5) Prototypes - Pros:

– Are mock-ups of screens and/or windows– Often used do define user interfaces which implies

functionality!!! Great user-interface prototyping tools available –

Extremely conducive to communications between user groups and developers.

Early changes to screens set stage for fewer changes later and reduced overall costs!

Greatly facilitates stakeholder acceptance later…

2222/37/37

Standard Approaches (5 of Standard Approaches (5 of 5)5)

Prototypes - Cons:– But, some pay more attention to screen than

functionality.– Executives may fail to realize prototype is not a

working system.– Want it right away

– A throwaway – Get buy-in on the throw-away – unless the development strategy (small systems) is to hone the prototype into a compliant application).

– Prototypes imply more is ‘done’ than is done. Only represent front end (presentation) and do not usually

represent the business rules. up front At best (but very good!) a great way to determine the user

interface specification.

2323/37/37

Statement of Statement of NeedNeed

“The system will allow students to register for courses, and change their registration, as simply and rapidly as possible. It will help students achieve their personal goals of obtaining their degree in the shortest reasonable time while taking courses that they find most interesting and fulfilling.” (p. 107, OOSE)

Very meaningful to the Stakeholder.

2424/37/37

Map: Needs to Map: Needs to FeaturesFeatures

Define features of system that meets needs of the stakeholders.

While performing this step, it can be helpful to continually relate the features of your proposed solution back to user needs.

This may be accommodated using a mechanism (simple table) called a traceability matrix.

2525/37/37

xx xx

xx xx

xx xx

Need #1

Feature #1

…

Need #n

Need #2

Feature #2 Feature #m…

Traceability Matrix – Leffingwell article

The Stakeholder needs are in the first column and the application features that we have defined to meet those needs constitute the columns.

Features are normally found in the Product Vision document for the Application.

2626/37/37

Traceability Matrix Traceability Matrix (more)(more)

We put Xs in the cells under the features that we have defined to satisfy the stakeholder needs.

Please note that this is a 1:n mapping, as there are far more features than explicitly stated Needs.

Further, the Needs are at high levels of abstraction. Study matrix. No X under a feature? Perhaps Need is not mapped

into feature(s)! Flag!! Features not traced back to a Need? Perhaps we

have Features that are not traceable back to Needs!

2727/37/37

Needs to Feature MappingNeeds to Feature Mapping Maybe the Needs or Features are not clear!Maybe the Needs or Features are not clear! Too, we are Too, we are notnot dealing with a dealing with a lot of informationlot of information

here, so this traceability should be undertaken.here, so this traceability should be undertaken.

Leffingwell: “Once you've mapped the need-feature relationships and have determined that the needs and features are correctly accounted for and understood, it's time to consider the next level of the hierarchy:

Relationships between the features and the use cases.”

2828/29/29

Continue the Traceability Continue the Traceability MappingMapping

From the From the Product Vision Product Vision DocumentDocument for the Application, for the Application, which contains the desired which contains the desired FeaturesFeatures derived from derived from Stakeholder Stakeholder NeedsNeeds, we need to , we need to mapmap the Features to the Features to Use CasesUse Cases..

Consider the next two slides:Consider the next two slides:

2929/29/29

We continue with this figure – to the figure on the next slide…

3030/29/29from Leffingwell’s article. This figure says a great deal!!!

ProductFeatures,and more

This is what we are after….