1 / 50

Requirements Engineering

Requirements Engineering. Nupul Kukreja , Barry Boehm 9 th September 2013. Team Mixer after class in Engineering Quad (outside OHE). Agenda. Part 1 Pervasiveness of Software Motivation for Requirements Engineering

oriana
Download Presentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering NupulKukreja, Barry Boehm 9thSeptember 2013

  2. Team Mixer after class in Engineering Quad (outside OHE) Agenda • Part 1 • Pervasiveness of Software • Motivation for Requirements Engineering • Interrelationships: Requirements Engineering, Enterprise & Software Development • Types of Requirements • Goals of Requirements Engineering • Framework for Requirements Engineering • Part 2 • Requirements Practice in 577 • System and Software Requirements Document • User Stories • Documenting Requirements in 577

  3. Pervasiveness of Software • Software-intensive systems prevalent across industries/domains • E.g.: automotive, finance, consumer electronics, medical devices etc., • Information systems: • Collects, stores, transforms, transmits, and/or processes information or data • Goal: Provide information at right place/time • Ex.: Accounting system • Embedded software-intensive systems: • Software only ONE (important) part of overall system • Often closely integrated with hardware • Ex.: Anti-lock braking system of a car

  4. Challenges in Software Development • Software-based innovations • Customers demanding innovative features  software is key for realizing innovation • Increasing Complexity • Greater number of functions realized by software  increasing complexity i.e., increased integration with external systems, customizability etc., • Higher quality demands • Pervasiveness of software  higher level of quality • Shorter development times • Increasing competition  faster time to market • Pressure to reduce costs • Increasing market pressure  software systems must be developed at lower costs

  5. Project Success Rate Challenged: Over budget/schedule or undelivered projects Failed: Cancelled projects

  6. CHAOS ’10 – Factors Influencing Project Success • User Involvement • Executive Support • Clear Business Objectives • Emotional Maturity • Scope Optimization • Agile Process • Project Management Expertise • Skilled Resources • Execution Capability • Tools and Infrastructure Lack of Stakeholder involvement and convergence viewed as major causes of project failure

  7. In-class • Create a means for protecting a small group of human beings from the hostile elements of their environment • List or draw or describe the “creation” in a couple of lines • Note down questions you may have 2 Minutes

  8. Why Is RE Important? • Flawed requirements a major cause of project failure • Fixing an error in later phases 10x more expensive • Incorrect requirements ↔Incorrect system leads to wasted costs • System maybe unreliable for practical use disrupting normal day-to-day operations • The primary vehicle for going from “vision” to “realization”

  9. RE and the Enterprise Marketing Market needs and trends, Price range New Features Requirements Engineering Product roadmap/ strategy, key requirements Realized changes and enhancements Product Management Customer Relationship Management New and revised requirements Customer wishes, Reported problems

  10. RE and Software Development Project plan, Approved goals Requirements & constraints Project Management Design & Development Monitoring data, Elicited goals Solutions, New technologies Requirements Engineering Requests for clarification and improvement Status of change requests Quality Assurance System Maintenance Requirement Artifacts Change requests

  11. Defining “Requirement” IEEE 610.12-1990: • A condition or capability needed by a user to solve a problem or achieve an objective • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents • A documented representation of a condition or capability as in (1) or (2)

  12. Types of Requirements • Functional Requirements: specify the functionality the system shall provide to its users • Ex.: The system shall allow the users to access their profile page after they provide valid credentials • Quality Requirements (a.k.a., Levels of Service): define the quality properties of the entire system or of a system component, service or function • Ex.: Reliability, performance under high loads etc., • “-ilities”: Availability, flexibility, scalability, usability, robustness, interoperability etc., • Constraints: Organization or technological requirement that restricts a way in which the system shall be developed • Ex.: Legal constraints (Sarbanes-Oxley), Project/Budget/ Schedule constraints, Physical constraints etc.,

  13. Goal of RE: Establishing a Vision in Context • Requirements Engineering processes start with an aim tochange 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

  14. Goal of RE: Establishing a Vision in Context • Each system is embedded within a given context • Context (a.k.a. “system context”): Part of the system environment relevant for • Defining, understanding & interpreting system requirements

  15. Visualizing “Vision” in “Context” • Establish system vision within existing system context • Deal with parts of the real world that are relevant and their relation to the development context Vision defines focus

  16. Framework For RE System Context Validation Core Activities Management Requirements Artifacts

  17. Framework For RE System Context Subject FacetMaintain information about objects/events in the real world. Usage Facet Desired workflows, usage goals, different user groups, interaction models, laws & standards etc., IT System FacetExisting hardware, software, communication networks, peripheral devices etc., Development FacetProcess guidelines and constraints, QA methods, maturity models, development environments etc.,

  18. Relationship Between Facets IT System Facet Subject Facet Representation Presentation Application Usage Facet Development Facet RE happens here!!

  19. Three Dimensions & Goalsof Requirements Engineering • Content: • All relevant requirements are explicitly known and understood at the required level of detail • Agreement: • A sufficient agreement about the system requirements is achieved between the success critical stakeholders • Documentation: • All requirements are documented and specified in compliance with the relevant documentation/specification formats & rules

  20. Visualizing The “Three Dimensions” Content Goal complete Agreement consolidated views vague individual views Documentation informal compliant with rules

  21. Framework For RE Core Activities Documentation Document & specify elicited requirements as per defined documentation and specification rules. Also capture rationale and other relevant information Negotiation1.Detect conflicts and make them explicit 2. Resolve identified conflicts Elicitation

  22. Framework For RE Elicitation Identifying Requirement SourcesStakeholders Existing Documentation Existing System(s) Developing new & innovative requirementsTypically not elicit-able and require collaborative and creative processes Elicit Existing Requirements Elicit already “known” requirements from relevant sources

  23. 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

  24. 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 requirementsData Model, Functional Model, Behavioral Model

  25. 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 Validation

  26. 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

  27. 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 Management

  28. 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)

  29. Part 2 Requirements Practices in 577ab

  30. 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

  31. 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 • Necessary to future proof the system

  32. Example of Capability Requirement

  33. Levels of Service Quality attributes of the system: • Dependability • Reliability • Availability • Usability • Ease of learning • Ease of use • Performance • Maintainability • Portability • Interoperability • Reusability

  34. 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)

  35. SSRD in Practice Too much detail and too much to capture The true 3D view In 2D

  36. Change Management & SSRD?

  37. Along came a Story User Stories SSRD What we thought… What was actually intended…

  38. The User Story – 3Cs A promissory note of intent Discussion & clarification of intent (a.k.a requirement) Acceptance Tests Card Conversation Confirmation Lightweight Ecstasy

  39. User Stories • Written on small index cards • Usually of the form: As a <role>, I can <activity> so that <business value> Ex.: As a Consumer I want to be able to see my 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 • Formalized via acceptance tests

  40. INVEST-ing in User Stories Commonly used acronym in the Agile World to describe attributes of a good user story:

  41. Theory-W STOP THIS MADNESS! Customer Dr. Boehm Think of requirements as stakeholder negotiated win conditions!! Developer As a team discuss what will make each of you “win” (a.k.a. win conditions) Reach a mutual consensus and move forward (WinWin Equilibrium) Identify any issues and come up with options to resolve them

  42. Putting It All Together Winbook Theory - W Requirement Specifications User Stories Gmail Facebook

  43. 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!

  44. Requirements in 577 • Requirements are treated as “Win Conditions” • Win Conditions are captured in Winbook • Win Conditions subsume user stories: • Capability/Functional 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”

  45. 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

  46. 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’

  47. 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

More Related