CS4566 Spring 2016 1

CS4566

Requirements Engineering

Lecture #2

Recap from the first lecture...

� Did I mention any names?

� Any dates?

� Anything at all?

� Did you take any notes?

CS4566 Spring 2016 2

Recap from the first lecture...

� Definition of a requirement:

� A capability needed by a system or product and/or the statement of that need◦ That’s 2 things!

◦ And that is a problem.

� What Requirements Engineering is concerned with...◦ Is that important to you?

� Can Requirements Engineering be a job?

CS4566 Spring 2016 3

Complete the sentence:

� I need to know about requirements engineering because someday I want to:

◦ A be a product/interaction designer

◦ B become a software architect

◦ C be a business analyst

◦ D become a product manager

◦ E work with one or more of those.

A lot of things in RE come in twos...

CS4566 Spring 2016 4

Such as

Two Assignments:

1. Elicitation assignment – 20%

2. Pecha Kucha – 10%

CS4566 Spring 2016 5

A lot about RE comes in twos:a. RE is an art, versus

b. It’s a science. (or the practice vs. the theory of RE)

a. It is hard, versus

b. It is easy. (In fact it is both hard and simple, but not that easy. )

A lot of things in RE come in twos, such as:

� Specification and Implementation

� Specifications versus Descriptions

� Problems and Solutions

� Did we mention Verification and Validation?

� System requirements and software requirements

� Functional requirements versus non-functionalrequirements (NFRs)

� Requirements (Analysis) vs. Design.

CS4566 Spring 2016 6

Requirements versus Design? � A false dichotomy

� Requirements engineering is Design…. Why?

� Requirements are not ‘out there’ to be captured or gathered. They might be discovered...

� They are decided upon ◦ by people

◦ for people

◦ And people often make mistakes…or change their minds, so...

� These decisions are not fixed.

Decisions, decisions, designs...

CS4566 Spring 2016 7

Requirements Activities and Outcomes (1)

� Elicitation◦ Informal statements of needs

� Negotiation◦ Agreed requirements

� Specification◦ Various drafts◦ Increasing formality◦ Increasing precision

� Representation◦ Models of the problem◦ Understanding of the problem

Requirements Activities and Outcomes (2)

� Verification◦ Correctly stated requirements

� Validation◦ The correct requirements

� Management◦ Changed requirements◦ Requirements traced to design and code◦ Code and design traced to requirements.

CS4566 Spring 2016 8

The RE process

� It’s a process, not a step

� Initiated at the beginning of the project (or life cycle)

� Continues in subsequent stages, but

� The role of requirements practitioners is more important at some stages than others…

� An on-going process

� A cycle…

Compare with ‘Roadmap’ activities

� Eliciting

� Modelling and analysis

� Communicating

� Agreeing

� Evolving

Roadmap = Nuseibeh and Easterbrook’s famous paper on RE

CS4566 Spring 2016 9

Product(s) of the Process

� A document?

� Two documents?

� Sometimes: a database of requirements

� Two levels:

◦ Customer oriented - brief

◦ Developer oriented – detailed

� Often the basis of a contract ◦ between the C and the D

� where C is for Client!

Outcomes of the process

� An informal statement of requirements

� Agreed requirements

� Various drafts and versions of the requirements documents

� The ‘final’ version◦ If you could call it that

� Change happens ◦ Requirements management is an essential part

of the process.

CS4566 Spring 2016 10

2 levels of requirements document:

� According to Ian Sommerville:

1. Requirements definition

2. Requirements specification

� However, this terminology is not widely observed in practice…

� Some say External and Internal specification

� Others say “Concept of Operations” and SRS

◦ (Software Requirements Specification).

People or Things?

�Three Requirements Discovery Contexts:

1. From Individuals

2. From Groups

3. From Things