Transcript Requirement - Software Engineering II
Requirements Engineering Nupul Kukreja, Barry Boehm 7
th
September 2012
1
Agenda
• • Part 1 – – Defining Requirements Engineering (RE) Why is RE important?
– – Vision, Context and relation to RE Three Dimensions of RE – Generic RE Framework Part 2 – – Requirements Practice in 577 System and Software Requirements Document – – User Stories Documenting Requirements in 577 2
Requirements Engineering
• • • Specifications of what should be implemented or as a constraint of some kind on the system Defined during the early stages of system and software development Types: – – General property of the system (e.g. response time) Detailed behavioral description (step by step scenario) – Specific constraint (must communicate with Amazon’s web service) – Information about computation details (e.g. interest computation for loans/mortgages etc., 3
Requirements Engineering*
• • Engineering implies application of systematic and repeatable processes A systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system
*http://en.wikipedia.org/wiki/Requirements_engineering
4
Requirements Engineering*
A cooperative, iterative and incremental process which aims at ensuring that: 1. All relevant requirements are explicitly known and understood at the required level of detail 2. A sufficient agreement about the system requirements is achieved between the stakeholders involved 3. All requirements are documented and specified in compliance with the defined documentation/specification formats and rules
*Requirements Engineering: Fundamentals, Principles & Techniques – Klaus Pohl
5
Why Is RE Important?
• • • • • Flawed requirements a major cause of project failure – one of top ten failures in Standish CHAOS Reports Fixing an error in later phases 10x more expensive Incorrect requirements leads to wasted costs Incorrect system System maybe unreliable for practical use disrupting normal day-to-day operations The primary vehicle for going from “vision” to “realization” 6
Understanding “Vision”
• • Requirements Engineering processes start with an aim to change current reality Vision: (a.k.a “system vision”) – Essence of desired change defined briefly and precisely – Describes overall goal(s) of the system – Usually associated with particular point in time of when the vision should be realized – Serves as a guide during development for all Success Critical Stakeholders (SCS) involved in the project 7
Understanding “Context”
• • Each system is embedded within a given context (a.k.a. “system context”) Context: Part of the system environment relevant for: – Defining – Understanding & – Interpreting system requirements 8
Visualizing “Vision” and “Context”
Vision defines focus • Establish system vision within existing system context • Deal with parts of the real world that are relevant and their relation to the development context 9
Requirements Engineering: “Three Dimensions”
• • •
Content:
Understanding of the system requirements attained
Agreement:
Level of agreement achieved between stakeholders about defined requirements
Documentation:
Documenting and specifying the requirements using different documentation and specification techniques 10
Visualizing The “Three Dimensions”
Content Goal
complete
Agreement
consolidated views vague individual views informal compliant with rules
Documentation
11
Framework For RE
System Context Core Activities Requirements Artifacts 12
Framework For RE
System Context
Subject Facet
Maintain information about subjects in the real world. (Subjects subsume objects)
Usage Facet
Desired workflows, usage goals, different user groups, interaction models, laws & standards etc.,
IT System Facet
Existing hardware, software, communication networks, peripheral devices etc.,
Development Facet
Process guidelines and constraints, QA methods, maturity models, development environments etc., 13
Framework For RE
Core Activities
Documentation
Document & specify elicited requirements as per defined documentation and specification rules. Also capture rationale and other relevant information
Negotation
1.Detect conflicts and make them explicit 2. Resolve identified conflicts
Elicitation
14
Framework For RE
Elicitation
Identifying Requirement Sources
Stakeholders Existing Documentation Existing System(s)
Elicit Existing Requirements Developing new & innovative requirements
Typically not elicit-able and require collaborative and creative processes Elicit already “known” requirements from relevant sources 15
Techniques For Elicitation
• • • • • • Interviews Workshops Focus Groups Observation of stakeholders/users etc., Questionnaires Perspective-based reading Usually supported by “Assistance Techniques” – Brainstorming – Prototyping – Mind Mapping – KJ Analysis/Method – Elicitation Checklists 16
Framework For RE
Requirements Artifacts
(Documented Requirements)
Goals
Stakeholder intention with regard to the objectives, properties or use of the system
Scenarios
Positive/Negative, Misuse, Exploratory, Current-state/desired state, Main, alternative or exception
Solution oriented requirements
Data Model, Functional Model, Behavioral Model 17
Framework For RE
• • •
Validation of context consideration
Check whether all relevant aspects in 4 contexts have been elicited, documented within the RE process
Validation of execution of activities
Check adherence of activities to process, standards, guidelines etc.
Validation of requirement artifacts
Check documented requirements w.r.t. content, documentation and agreements 18
Validation Techniques
• • • • Inspections Walkthroughs Desk-checking (checking programs with pen-paper) Prototyping • • • • Above are usually assisted by: Validation checklists Perspective-based reading Verbalization of models Creation of artifacts 19
Framework For RE
• • •
Observation of system context
Identification and management of context changes
Management of RE activities
Monitoring, controlling and adjustment of planned workflow of elicitation, documentation, negotiation and validation activities – standard project management
Management of requirements artifacts
– Establishing traceability between different artifacts – Prioritizing requirements – Managing changes via change management processes 20
RE Framework == VBSE 4+1
• • • RE Framework advocated by Klaus Pohl is in essence isomorphic to VBSE’s 4+1 VBSE brings value considerations to the foreground; RE Framework doesn’t seem to make it explicit Each of the ‘steps’ of the RE framework is traceable in VBSE’s 4+1 structure (and vice versa) 21
Part 2
Requirements Practices in 577ab 22
RE Framework and 577
System Context
QMP Subject Facet
Maintain information about subjects in the real world. (Subjects subsume objects)
SSAD Usage Facet
Desired workflows, usage goals, different user groups, interaction models, laws & standards etc.,
IT System Facet
Existing hardware, software, communication networks, peripheral devices etc.,
Development Facet
Process guidelines and constraints, QA methods, maturity models, development environments etc.,
OCD SSAD LCP
23
RE Framework and 577
Core Activities
Documentation
Document & specify elicited requirements as per defined documentation and specification rules. Also capture rationale and other relevant information
Winbook Elicitation Negotation
1.Detect conflicts and make explicit 2. Resolve identified conflicts
WinWin Sessions
24
RE Framework and 577
Elicitation
Identifying Requirement Sources Elicit Existing Requirements Developing new & innovative requirements
Stakeholders Existing Documentation Existing System(s)
Result Chains On-site Visits
Elicit already “known” requirements from relevant sources
WinWin Sessions
Typically not elicit-able and require collaborative and creative processes 25
RE Framework and 577
Requirements Artifacts
Goals
Stakeholder intention with regard to the objectives, properties or use of the system
Result Chains OCD Scenarios
Positive/Negative, Misuse, Exploratory, Current-state/desired state, Main, alternative or exception
SSAD Winbook Solution oriented requirements
Data Model, Functional Model, Behavioral Model 26
Prototyping
RE Framework and 577
IIV & V
Project Management (Winbook) Prioritization Lifecycle Planning Feasibility Analysis Bugzilla Change Management ARBs
27
• • • • • • •
Requirements Capturing in 577
Previously captured in System and Software Requirements Document (SSRD)
Capability requirements (both nominal and off-nominal): i.e., the fundamental subject matter of the system, measured by concrete means like data values, decision-making logic and algorithms. Level of Service Requirements (sometimes referred to as Non-functional requirements): i.e., the behavioral properties that the specified functions must have, such as performance, usability, etc. Global constraints: requirements and constraints that apply to the system as a whole e.g.: Interface Requirements, Budget and Schedule Requirements, Implementation Requirements, and other Project Requirements Evolution Requirements: not included in initial delivery, but need to be supported by the System ’ s Architecture Priorities on how the system must be implemented : MoSCoW( Must Have, Should Have, Could Have, Want to Have) Commitment: addressing WinWin agreements, policies, constraints 28
• • • •
Main Kinds of Requirements
Product Requirements – Capability Requirements • local to system, specific system functionality – Level of Service Requirements • local to system, may affect many system requirements System Interface Requirements – varies, affects groups system requirements Project Requirements – global to project, affects overall system requirements Evolutionary Requirements – varies, effects design and implementation 29
Example of Nominal Requirement
Requirement: Description: Priority: Input(s): Source(s): Output(s): Destination(s): Pre-condition(s): Post-condition(s): WinWin Agreements:
CR-13 The Archive user subsystem allows the user to view the list of archive items, select the item of interest, deselect if required and view the overview on the selected archive items.
Must Have - Selected archive items - The database with the overviews of the archive items.
User Input Overview display of the archive items.
User Display The user has performed a search by keyword or has browsed the archive.
The user either makes an advance request or starts another search or exits from the system.
[Agreement 1] 30
Examples of Levels of Service
• • • • • • • Dependability – Reliability – Availability Usability – Ease of learning – Ease of use Performance Maintainability Portability Inter-operability (or binary portability) Reusability 31
Poor Examples of LOS
• M: The system should be as fast as possible • R: The system should be available 24/ 7 (even if organization does not support activities beyond day time) • S: The system shall be implemented as per the standards laid out by USC • A: The system shall be available 100% of the time (for an unreliable network- based system) 32
SSRD in Practice
In 2D The true 3D view Too much detail and too much to capture 39
Change Management & SSRD?
40
Along came a Story
What we thought…
User Stories
What was actually intended…
SSRD
41
A promissory note of intent The User Story – 3Cs Discussion & clarification of intent (a.k.a requirement) Acceptance Tests Confirmation Card Conversation Lightweight Ecstasy 42
User Stories
• • • • Written on small index cards Usually of the form: As a
daily energy usage so that I can lower my energy costs and usage
Lacks details captured by traditional requirements specifications Details conveyed primarily through conversations 43
INVEST-ing in User Stories
Commonly used acronym in the Agile World to describe attributes of a good user story:
I N V E S T
= Independent = Negotiable = Valuable = Estimable = Small = Testable 44
Dr. Boehm Customer
Theory-W
Developer Think of requirements as stakeholder negotiated win conditions!!
As a team discuss what will make each of you “win” (a.k.a. win conditions) Identify any issues and come up with options to resolve them Reach a mutual consensus and move forward (WinWin Equilibrium) 45
Facebook Putting It All Together
Winbook
Theory - W Requirement Specifications User Stories Gmail 46
• • • •
Winbook
A collaborative, social networking based tool for requirements brainstorming similar to facebook… …with requirements organization using color coded labels similar to Gmail… …to collaboratively converge on software system requirements reaching win-win equilibrium (based on Theory-W)… …by keeping it short and simple like XP’s user stories!
47
48
49
Requirements in 577
• • • • • Requirements are treated as “Win Conditions” Win Conditions are captured in Winbook Win Conditions subsume user stories: – Capability Requirements/Win Conditions can be conveniently phrased as user stories Win Conditions are negotiated within Winbook itself Win Conditions are linked to corresponding use cases facilitating “downstream value traceability” 50
Challenges in RE
• Things that can (and do) make life difficult – – Missing Requirements Ambiguous Requirements (major problem) – Changing Requirements (changes in technology, marketplace, political & legal changes, economic changes etc.,) – – Non-identified Stakeholders Location/Time differences and communication overhead – – IKIWISI (I’ll know it when I’ll see it) Implicit Assumptions 51
Key Takeaways
• • • • • • • Requirements are very critical to the field of Software Engineering Almost everything documented information is a form of requirement No single artifact to rule them all – content usually split across various artifacts Very cooperative and iterative Assumptions/Conflicts must be made explicit and validated/resolved SSRD is more commonly found in the wild 577 uses Winbook for documenting ‘requirements’ making the process ‘fun and lightweight’ 52
References
• • • • • Requirements Engineering: Fundamentals, Principles and Techniques – Klaus Pohl Agile Software Requirements – Dean Leffingwell Exploring Requirements: Quality Before Design – Gause & Weinberg User Stories Applied – Mike Cohn Software Engineering Economics – Barry Boehm 53