Requirements Engineering

CSCU 411 Ch 9

LEARNING OBJECTIVES

• To understand that requirements engineering is a cyclical process involving three types of activity: elicitation, specification, and validation

• To appreciate the role of social and cognitive issues in requirements engineering

• To be able to distinguish a number of requirements elicitation techniques

• To be aware of the contents of a requirements specification document

• To Know various techniques and notations for specifying requirements

• To be aware of different perspectives and aspects that may be distinguished in modeling requirements

Library

• List of books by…

• List of books with XXXX in title

• List of books an topic XXXX

• List of books that arrived after a date

Library

• Store info on books ordered but not received

• Store customer info and date books are due

Library Design

• System?– O/S– DBMS– User interface (terminals, PCs) How Many

• Type of user– General– Members– Staff

• Permissions– Read– Read/Write– PRINT

Library Design

• Size of DB– Search types– Growth– Limits?

• Response time– Search results

• Local• Other branches?

• Cost– Software– Hardware– Training

• Procedures change• Some staff become redundant

– Is it worth it?• Non technical aspects

Library Design

• Requirements elicitation

• Requirements specification

• Requirements validation and verification

Requirements Elicitation

• Functionalism (objective-order)

• Social-relativism (subjective-order)

• Radical-structuralism (objective-correct)

• Neohumanism (subjective-conflict)

• Democratic

• Network

Requirements Elicitation Techniques

Requirements Elicitation

• Task Analysis– What normally happens– What we wish happened– What can happen– What we decide on– Scenarios

Business Process Redesign (BPR)

• 1. Identify processes for innovation.

• 2. Identify change levers

• 3. Develop process visions

• 4. Understand the existing process

• 5. Design and prototype

THE REQUIREMENTS SPECIFICATION DOCUMENT• A requirements specification should be correct• A requirements specification should be unambiguous• A requirements specification should be complete• A requirements specification should be (internally)

consistent• Requirements should be ranked for importance or stability• A requirements specification should be verifiable• A requirements specification should be modifiable• A requirements specification should be traceable

THE REQUIREMENTS SPECIFICATION DOCUMENT• Details we must look at

– Mode. Systems may behave differently depending on the mode of operation

– User class. Different functionality Day be offered to different classes of users (login type)

– Objects. Requirements may be classified according to the objects in the real world

– Response. Some systems are best described by placing together functions that generate response

– Functional hierarchy. When no other classification fits

REQUIREMENTS SPECIFICATION TECHNIQUES • Noise• Silence• Over-specification• Contradictions• Ambiguity • Forward references• Wishful thinking

Entity-Relationship Modeling

State Machines

Structured Analysis Design

SADT and our Library

A MODELING FRAMEWORK

• The business perspective

• The information perspective

• The functionality perspective

• The implementation perspective

A MODELING FRAMEWORK

• Consider the following:– Goals and constraints– Function In to Out

• Fees • Members• (white Box)

– Data• Types, attrib, relations, constraints

– Organization• Structure• Quality of work

– Technical Structure• Hardware• Users• Infrastructure

– Distribution• Locations• Machines

Verification and Validation

• Checking against the requirements document– Correct – Complete– No ambiguity– Consistency