Transforming how companies work with technology.

Requirements Seminar

What is a Requirement?

Something that the product must do or a quality that the product must have

Things you should discover before starting to build your product

What is a Requirement? What the Stakeholder

Needs Wants Asks for Expects Can have

A set of specific criteria that a product must meet in order to be acceptable to the stakeholders

“Your customers are not buying a product. They’re buying your assurances that their expectations for that product will be met” - J Guaspari

What is a Stakeholder? People who have a vested interest in the

product – will somehow be affected by its use

People who have requirements for the product

Before you can identify all the requirements, you must identify all the stakeholders.

Include the list of stakeholders in your requirements specification.

Why do we need Requirements?

Define the product Define product quality Help control complex projects Help manage Stakeholder

expectations Improve compliance with: CMM,

ISO, IEEE, etc.

Capability Maturity Model (CMM)

Congress founded the Software Engineering Institute (SEI) at Carnegie-Mellon University in 1984 to improve the practice of software engineering.

First version of CMM published in 1989.

Mature = predictability is high,

risk is low

CMM (continued) Five levels of maturity

1. Initial (75% - 85%)

2. Repeatable (5% - 10%)

3. Defined (3% - 7%)

4. Managed (2% - 3%)

5. Optimized (> 2%) Each level defines Key Process

Areas (KPA) and key practices within each KPA.

CMM Level 2 Project-focused Formalize the planning and mgmt.

of individual projects. Six Key Process Areas (KPA)

1. Requirements mgmt.2. Software project planning3. Software project tracking4. Software quality assurance5. Software configuration mgmt.6. Subcontractor mgmt.

The Spirit of CMM Say what you do and do what you

say. For Level 2,

Repeat processes from project to project

Study the results Improve the process if necessary

Accumulate artifacts that substantiate the top bullet point.

Establish a Repeatable Process

Identify stakeholders Mine Define Refine Combine (requirements specification) Signoff Change control, reuse library

Identify Stakeholders Sponsor Current Users New Users Management Customers PMO Development team Legal Marketing

Government Industry Public Special interest

groups Existing IT

systems Production

support team ???

Mine for Requirements

Partners

Users

Analysts Business Plans Personal Goals

Domain ExpertsIndustry AnalystsSite VisitsCompetitive info

Problem Domain

Customers

Bug ReportsChange Requests

The Key Listen Re-state Do not stop until YOU have a clear

picture – YOU manage the expectations – YOU must have the vision.

Document your understanding Get signoff on your document

Requirements Should Address: Business impact Business need Impact on the organizational

processes Impact on the existing and

planned systems Business and technology strategies

Techniques for finding potential requirements

InterviewingJAD (Joint application development) Brainstorming Facilitated Sessions Prototyping Use Cases Usability Studies Document Gathering Inspection

More techniques for finding potential requirements

Surveys Business procedures and standards Data flow diagrams Client Liaison Data and process models Data dictionary definitions Existing code unit specifications Comments in existing code Reuse library

Stating Requirements Accurately

Essential Characteristics of Requirements Complete Unambiguous Consistent Verifiable Precise Detailed

Define Requirements - Requirement Attributes

Description Rationale Source Source date Unique identifier Requirement type Requirement sub-type Requirement level Priority Test Case

DescriptionUse consistent format

Verb - Modifier - Direct Object – (on condition)

Examples Capture (verb) customer (object modifier)

information (object). Calculate (verb) monthly interest (object

modifier) payments (object). Issue (verb) warning (object modifier) alert

(object) on error (condition).

Emphasize “what” not “how”.

Types of Requirements Functional requirements

What will the product do? What, not how

Non-functional requirements What qualities must the product

have? Constraints

What limitations exist regarding the way the product is produced?

Sources of Requirements

Client requirements Technical requirements Audit and control requirements Corporate standards Operational requirements Regulatory bodies

Additional Sources of Requirements

Manual and administrative requirements

Scheduling and performance requirements

Database requirements Security requirements Audit and control requirements

Refine Requirements Must pass quality check before

being added to requirements specification and database.

Must verify and validate. Decomposition

The Need for Quality Requirements

60% - 66% of errors originate with requirements and analysis activities.

45% of problems requiring maintenance are detected after completing acceptance tests.

The cost of fixing problems during final testing is 50-100% higher than during requirements specifications.

What Is Quality? The level with which a product

meets all its defined requirements; Therefore,

You can’t measure quality without fully defining the requirements

Each requirement should be measurable/testable.

Verify and Validate Requirements validation and

verification are the joint responsibility of the test analyst and the client/end user.

Validating requirements before coding begins minimizes costly design and code modification.

Acceptance and Integration tests begin by validating that the requirements meet user’s expectations and are testable.

Validating requirements

Requirement

Validate sign-on

Validate password

Invalid term ident

Password/ Signon error

Validate Main Menu

Re-enter O, X, M, R

Validate Customer #

Customer # Required

Field entry too long

Customer ___ not found

Test Case1 2 3 4 5 6x

x

x

x

x

x

x

x

x

x

Decomposition

Identifying requirements in a top-down fashion

Process of refining requirements Requirements are categorized at three

major levels of detail: High Intermediate Detail

Decomposition High Level Requirements

Broadest category of functions Major business processes Operations manuals, user manuals,

procedures External systems interfaces System controls

Special requirements Volume/Stress requirements Backup/Recovery requirements Performance requirements

Used to define and validate the build structure

Decomposition Intermediate Level Requirements

Components of intermediate level requirements may include:

Sequences of actions to be taken Information to be displayed or reported Error routines and messages Interfaces to other system modules Transaction descriptions

Edit, update, etc. Used to define and validate test runs

Decomposition Detail Level Requirements

Specific steps in application processing, such as:

Action steps Field definitions Edit criteria Calculations Error messages

Used to develop test cases

Validating Detailed Requirements

Requirements Decomposition Complete when each defined requirement

can be validated by one or a small number of test cases

If you can not develop a test case for a requirement, you need to dig further

If you are having difficulty developing test cases, other design activities focusing on the specific function in question should be stopped until requirements can be clarified or augmented

“BAD” words Watch Out For

Words Like: Often Always Sometimes Never Usually Fast User friendly Timely

Most of the time Quickly Could Might/May Good Satisfactory

Be careful of: Unintended implications of

certainty always, never

Passive tense phrases the counter is set

Pronouns for which references are not clear

Unclear comparatives earlier easiest most valuable

And… Unqualified attributes

flexible, efficient, organized

Ambiguous words quickly, adjacent

Contractually troublesome phrases where applicable

Combine and Review Produce requirements specification Should include

Product purpose List of Stakeholders and their roles Constraints Assumptions Functional requirements Non-functional requirements

Consistency check, missing requirements

Obtain Signoff Client understands the system IT understands the requirements Go directly to change control

Change Control No requirements are changed, added or

deleted without going through the change control process.

A change request form is filled out specifying the requested change, the source and why the request is being made.

The change is analyzed and the potential impact is added to the form.

Change control board reviews and sponsor signs off.

Reuse Library Collection of artifacts Enables repeatability Saves time, effort, re-work Many constraints will likely be the

same Stakeholder list will likely be similar Use items as needed

Lessons Learned What techniques were used to

identify requirements? How well did they work? Can they be improved upon? Document

Discussion

Contact Info:

Bill Ax – Account Executive

608-233-8201

billax@spherion.com

Mike Lawler – SQM Practice Director

630-919-2912

michaellawler@spherion.com