Software Requirements and Specification Requirements Process - - PowerPoint PPT Presentation

Software Requirements and Specification

Requirements Process

SE3821 - Jay Urbain

Requirements Process

1

Requirements

2

Requirements

No matter what product you are building, you still need to explore, understand, capture, and communicate requirements. For the right product to be built, the right requirements have For the right product to be built, the right requirements have to be discovered. … but requirements don’t come by accident.

3

Requirements Process

Need a systematic process. By following a systematic requirements gathering process, you can reliably discover product requirements. The principles of a good requirements gathering and specification process should transcend application types.

4

Requirements Process

• Requirements process should be iterative.

– E.g., when trawling/noodling for requirements you would probably gather requirements for one business use-case at a time.

• Requirements need to be written. Demonstrates the

requirements can be:

– communicated – understood

Once written, passed to a Quality Gateway for testing

– Either included in requirements spec (RS) or rejected

5

Volere Requirements Process

• Customer

needs/Product plan

• Work context
• Trawl

6

• Prototype
• Write
• Quality gateway
• Requirements Spec
• Reuse

Product Plan

Determine:

• Work Context
• Product Purpose

Product Plan Major Risks Initial Costs

7

• Product Purpose
• Stakeholders
• Business Constraints
• Project Constraints

Client Needs Work Context Business Events Major Risks

Work Context

WORK

8

• You can influence
• Possibly change
• Need to understand
• Intend to study

Project Purpose

• Describe the purpose of the product.

– One sentence on what the product should do – Write this from a “business” point of view

• What business advantage will this bring?
• What business advantage will this bring?

– Provide service that does not exist – Provide better service – Increase revenue – Streamline operations

• How will you measure the advantage?

– Numbers that can be tested – Quantified Goal

9

Stakeholders

• Anyone with an interest in the product.
• Missed stakeholders = missed requirements
• Core (Principal) stakeholders
• Producers (technical and business personnel)
• Client
• Client
• Customer
• Users
• Non-Core stakeholders

– Have knowledge needed by the core stakeholders – People who want to kill the project

10

Trawling (elicitation)

Determine:

• Product Scope

Stakeholder Input Work Context

• Product Scope
• Investigate Use Cases
• Brainstorm
• RAD meetings
• Scenario Oriented Elicitation

Business Events Reuse Repository

Requirements Specification

Trawl Prototype

Potential Requirement

What is more important?

• Written requirements or
• Process of writing them

12

Specify

Potential Requirement

Formalized Requirement

Requirements Specification

Quality Gateway Formalized Requirement

Why can requirements be rejected?

13

Gateway Rejected Requirement SRS

Waterfall Requirements

• Waterfall presentation of requirements gathering should

not be taken too literally.

– Activities typically iterate and overlay before producing a final

• utput.

14

Agility Guidelines

• Agility does not mean the “absence” of a process.
• Agility focuses on the parts of a process that are

appropriate for your project.

• Not all projects can be as agile as others. Why?

15

Project Agility

• Type of project often dictates level of agility:

– Number of stakeholders. – Scattering of stakeholders. – Documentation requirements – Scattered development teams. – Scattered development teams. – Legal.

• Animal metaphor for type of project is common.

– Rabbit – Horse – Elephant

16

Agility – Rabbit Project

• How would you describe an Rabbit Project?
• What level of agility and what parts of the requirements

process is appropriate for Rabbit Projects?

17

Agility – Rabbit Project

• High degree of agility
• Typically smaller projects with close stakeholder

participation

• Smaller number of stakeholders
• Good for XP
• Good for XP
• Best way to learn requirements is a whiteboard (versus

written documentation review)

• Prototypes and scenarios very important
• Important to understand different between req. & soln.
• Iterative requirements gathering, incremental

development.

18

Agility – Rabbit Project

• Problems with Rabbit Project?
• When not appropriate?

19

Agility – Horse Project

• How would you describe a Horse Project?
• What level of agility and what parts of the requirements

process is appropriate for Horse Projects?

20

Agility – Horse Project

• Halfway agile projects
• Use as much agility as possible (iterative, incremental)
• Usually have constraints (project & organization)
• Develop requirements for one unit of work (one business

use-case) while designers start development of previous use-case) while designers start development of previous use case.

• Requires the overall architecture to be in place before it

can work.

– How is the architecture factored into the process?

• Trawling, writing, and quality steps very important
• If done well, project can achieve a high degree of

effectiveness without getting bogged down.

21

Agility – Horse Project

• Problems with Horse Project?
• When not appropriate?

22

Agility – Elephant Project

• How would you describe a Elephant Project?
• What level of agility and what parts of the requirements

process is appropriate for Elephant Projects?

23

Agility – Elephant Project

• Least agile.
• Large dependable with long memories
• Agility may be limited by organization
• Large number of scattered stakeholders
• Formal, complete product requirements may be required

for domain, e.g., medical, aeronautical

• Contractual obligation
• Outsourcing
• Even with Elephant projects, look for ways to introduce

agility.

24

25

Requirements Process in Context

• No end to requirements process
• As soon as product is delivered, evolution starts
• As people use the product, they discover new needs,

new problems… which creates new requirements

• Embrace this evolutionary process from the start – then
• Embrace this evolutionary process from the start – then

iterate, and incrementally deliver functionality

26

27