230 likes | 362 Views
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
E N D
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 • 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
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