1. CSCI 6231 Software Engineering ( Chapter 10?) Requirements Workflow Instructor: Morris Lancaster

2. January 2011CSCI 6231 Chapter 102 Overview Slides on Text Material are Backup. Introduction Discuss –Eliciting requirements from clients –Modeling requirements –Reviewing –Documenting

3. Introduction Requirements Analysis –Capture what the customer wants –Negotiate/iterate on what we and the customer can agree to –And which is testable January 2011CSCI 62313

4. Importance of Requirements “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” Brooks, Frederick P., Jr. (1987). “No silver bullet: Essence and accidents of software engineering.” IEEE Computer, 20(4), April 1987: pp 10-19. January 2011CSCI 62314

5. Importance of Requirements In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to determine status of the industry –31% cancelled before completed –9% delivered on time and within budget in large companies –16% delivered on time and within budget in small companies Top reported factors contributing to failures –Incomplete requirements 13.1% ** –Lack of user involvement 12.4% ** –Lack of resources 10.6% –Unrealistic expectations 9.9% ** –Lack of executive support 9.3% –Changing requirements and specifications 8.7% ** –Lack of planning 8.1% –System no longer needed 7.5% **? January 2011CSCI 62315

6. Requirement An expression of desired behavior –Objects/Entities States that objects can be in Functions performed to change states or characteristics –Non-functional requirements Timeline –Extracted from the user –Refined at specification time (allocated to software) –Baselined as trace-back-to during implementation –Are basis for testing –Can change at any time January 2011CSCI 62316

7. Requirements Extraction An expression of desired behavior –Objects/Entities States that objects can be in Functions performed to change states or characteristics Timeline –Extracted from the user and other inputs –Refined at specification time (allocated to software) –Baselined as trace-back-to during implementation –Are basis for testing –Can change at any time January 2011CSCI 62317

8. Requirements Extraction Sources –Stakeholders The person/organization paying for the system Customers of the above who will purchase the system End users of the system Domain Experts Market Researchers Lawyers/Auditors Software Engineers –Consistency? One approach is to encourage inconsistency during the requirements process and document stakeholder views, maintaining them January 2011CSCI 62318

9. Requirements Extraction Sources - continued –Documentation Existing procedures/processes/system –Observation of the current system User performance of tasks –Apprenticeship with users –Products from Domain Specific Strategies such as JAD –Brainstorming January 2011CSCI 62319

10. Requirements Extraction Issues –Requirements are not well formed or well understood at the beginning –Customers are not able to describe what they want or need –It is difficult for the software engineer to rapidly understand someone else’s business concerns –Customers use their jargon and domain specific thought models as assumed baselines –The software engineer’s jargon and domain specific thought models interfere January 2011CSCI 623110

11. Requirements Extraction Types –Functional –Non functional (quality requirements, etc) Constraints –Design constraints (previously made, platform or product) –Process constraints (how we build it, customer whims, agile) January 2011CSCI 623111

12. Requirements Extraction Types (more) –Design constraints Physical environment Interfaces Users –Process constraints Resources Documentation –Quality constraints Performance Security January 2011CSCI 623112

13. Requirements Extraction Types (more) –Quality constraints Performance Security Reliability and availability Maintainability Precision and accuracy Time to delivery/cost January 2011CSCI 623113

14. Requirements Extraction Requirements Documents –Requirements Definition A complete listing of everything that the client wants to achieve –Requirements Specification Restates the requirements as a specification of how the proposed system shall behave January 2011CSCI 623114

15. Requirements Extraction Requirements Characteristics –Are the requirements correct? – review by all –Are the requirements consistent? – any conflicts, have views been reconciled? –Are the requirements unambiguous ?– be able to see the person on the hill with the telescope –Are the requirements complete? – ranges of inputs/outputs and operational environments specified with expected behaviors –Are the requirements feasible? –Is every requirement relevant? –Are the requirements testable? –Are the requirements traceable/ January 2011CSCI 623115

16. Requirements Extraction Testable –Once a requirement is stated, we should be able to determine whether or not a proposed solution meets the requirements –Evaluation must be objective Atmospheric humidity information must be accessible immediately Atmospheric humidity information must be retrieved within 5 seconds of a request January 2011CSCI 623116

17. Modeling Notations Modeling –Implements repeatable processes that can be used to achieve results within a given set of bounds –Many specification and design notation methods January 2011CSCI 623117

18. Modeling Notations Entity Relationship Diagrams (Chen – 76) –Entities, attributes, relationships –UML Class Diagram Name, attributes, operations, associations, generalizations, subclasses Event Traces –Sequence of events –Message Sequence Charts January 2011CSCI 623118

19. Modeling Notations State Machines –State transitions, possible state –UML Statechart Diagrams –Petri Nets Data-Flow diagrams –Data centric view with processes shown –Use Case Diagram Formal Approaches –Logic (temporal) –Set Theoretic (Z) –Algebraic Specifications January 2011CSCI 623119

20. Modeling Notations Also there are methodologies which incorporate multiple views The objective is to have a set of notations that can be used throughout the development or life cycle of the initiative An important characteristic is the ability to flesh out requirements iteratively (and follow ons to design and implementation) using all of the same tools we began with and that there are relationships (informational) between the notations/tools January 2011CSCI 623120

21. Prototyping Throwaway –We must introduce it as a visiting orphan, or –We must tear it from the tight grip of the user and throw it in the trash in front of them Evolutionary –The user will watch their child grow January 2011CSCI 623121

22. Requirements Definition Outline general purpose and scope Describe the background and rationale behind the proposed system Describe the essential characteristics of an acceptable solution Describe the environment in which the system will operate Outline any customer proposals for solving the problem Document all assumptions made about the environment January 2011CSCI 623122

23. Requirements Specification Document interfaces, inputs and outputs in detail, destinations, etc Restate functionality in terms of the interfaces’ inputs and outputs Devise fit criteria for each customer quality requirement. January 2011CSCI 623123

24. Verification and Validation Validation –Is it valid? –Do the requirements accurately reflect the customer’s Verification –Do the documents/artifacts produced thus far conform January 2011CSCI 623124

25. Verification and Validation Techniques Validation –Walkthroughs and formal inspections –Reading –Interviews –Reviews –Checklists –Scenarios –Prototypes –Simulation January 2011CSCI 623125

26. Verification and Validation Techniques Verification –Cross-referencing artifacts –Simulation –Checks for consistency and completeness –Checks for unreachable states, situations –Computer aided verification –Mathematical Proofs January 2011CSCI 623126

27. Summary Requirements definition and specification documents must describe the problem, leaving solution selection to the designers Large number of sources and means for collecting requirements Many different types of definition and specifications techniques Specification techniques differ in their tool support, maturity, understandability, ease of use, and mathematical formality. Requirements questions can be answered using models or prototypes. Requirements must be validated to ensure they accurately reflect the customers’ expectations January 2011CSCI 623127