Chapter 3 Requirements Ronald J Leach Copyright Ronald

Chapter 3: Requirements Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 1

Wrong Requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 2

What can go wrong? • Requirements can be inconsistent • Requirements can be incomplete • Requirements can be set correctly for a system that no one wants or will use Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 3

What if requirements are “wrong? ” • If requirements are inconsistent: – No system can be built to meet these requirements – Any activity based on assumptions about these inconsistent requirements must be redone – Disaster! – Fix requirements as early as possible – Most other software activities are irrelevant Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 4

What of requirements are wrong • If requirements are incomplete: • The problem is not too severe if the requirements were modular – A team experienced in the application domain is likely to be able to fill in the missing requirements – Additional effort and delays – The system may be built wrong Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 5

What of requirements are wrong • If requirements are incomplete: • The problem is severe if the requirements were not modular – A team not experienced in the application domain will have great difficulty filling in the missing requirements – The system is almost certain to be built wrong Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 6

Building the wrong system • If the system’s requirements do not meet the needs of known or supposed users – Unlikely to be used or sold – Why bother? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 7

Breakdown of sources of errors Requirements Many Design Somewhat fewer Code Somewhat fewer still Testing Somewhat fewer still Relative cost to fix errors at different life cycle phases Requirements 1. 0 Design 5. 0 Code 10. 0 Testing 30. 0 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 8

Requirements Elicitation Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 9

Requirements Engineering Process Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 10

In the very beginning … • Identify customers, users (the stakeholders) • Communicate with them • … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 11

In the beginning … Requirements must describe: • Hardware platform • Operating system • Multiple hardware and operating systems • File formats • GUI, COTS, DBMS, … • Delivery mechanism • … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 12

In the middle … • • Specify versions Performance characteristics System resources needed System Functionality Details Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 13

In the end … • Complete, consistent requirements • Build the system right • Make sure you are communicating with customers (prospective or surrogates) to build the “right system” Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 14

Requirements Traceability Matrix Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 15

Why a RTM? • To help determine if a requirement is testable • To help project management keep track of the status of the project Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 16

Requirements Traceability Matrix Number Requirement Design Code Test 1 Intel-based 2 Windows 8 3 Consistent with User Interface of Windows 8 Graphical User Interface Consistent With Mystery 3. 1 System One Size Only 9 <200 MB System, <500 MB Disk Share Data with Catchall 7. 3 On-line Help Provided 10 Delivery on CD 11 Include Installation And Decompression 4 5 6 7 8 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 17

Can each of these requirements be tested? • Describe a simple test for each one • If you can’t find a test, the requirement is too vague Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 18

What about more complicated requirements? • Most systems are far too complex to have this simple sequential arrangement of requirements • Stepwise refinement, better numbering systems to identify grouped requirements can help Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 19

Four general techniques Use data abstraction and information hiding to completely describe system functionality. Regroup requirements to be consistent with requirements and design of both existing and planned systems. Reuse requirements in order to reuse existing designs and source code previously developed to meet these requirements. Automate the requirements engineering process. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 20

Information Hiding Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 21

Information Hiding • Developed by Daniel and Orna Berry • Journal of Systems & Software Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 22

Information Hiding Principle 1 • Requirements must be modified and refined until the system can be developed by software designers and coders who are; – familiar with the fundamental algorithms of the application domain – ignorant about the requirements engineering process. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 23

Information Hiding Principle 1, cont. • The eventual requirements will be so complete and unambiguous that – the design will be clear – the coding can be done easily by implementing standard, well-known algorithms. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 24

Information Hiding Principle 2 • The requirements must be modified and refined until – the system requirements can be understood by requirements engineers who are knowledgeable about requirements engineering, but who know nothing about the application domain. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 25

Information Hiding Principle 2, cont. • The eventual requirements will be so complete and unambiguous that – the requirements engineer will understand them completely, even without knowledge of the application domain. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 26

Requirements and Reuse Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 27

Reuse-Driven Requirements • A process that can help customers reduce costs and still get the system they want. • There may be existing components that meet the customer’s essential requirements, but might not meet all the requirements stated initially. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 28

Reuse-driven requirements 1. Get requirements from customer. 2. If an existing system meets requirements, done. 3. If not, perform domain analysis – Determine existing system closest to customer requirements. – Negotiate requirements with customer to determine if agreement on a lower cost system meeting fewer requirements. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 29

Reuse-driven requirements – If customer will not accept new proposed solution with reduced requirements, decompose system into subsystems. – Use domain analysis classification scheme for decomposition into subsystems. – For each subsystem, produce existing new subsystem that either matches subsystem requirements or is closest to them. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 30

Reuse-driven requirements – Negotiate reduced subsystem requirements with customer – Allow selecting a subsystem with reduced functionality. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 31

Reuse-driven requirements – Each negotiation with customer will include detailed descriptions of the tradeoffs in capability vs. reduced cost of system. – Estimation of integration and maintenance costs is essential at each stage. – Continue the process of domain and system decomposition as much as necessary. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 32

Reuse-driven requirements • The algorithm was quite detailed and required intensive customer interaction. • New code is to be written only as a last resort. • COTS-only systems are the extreme case of this process. • Few models: (Waund, Ellis at Loral, Kontio, Basili at Maryland, IMMACS project at NASA/Goddard). • Barry Boehm has a related approach called "winwin. ” • Highly useful in agile processes Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 33

Applying this approach • The process depends upon negotiation with a customer. • If there is no known customer, as is the case with much commodity software, the process won’t work. • The process also does not apply to safetycritical systems, in which requirements are rarely negotiable. • It can work in any other environment in which the customer is highly motivated by cost. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 34

Summary • Reuse-driven requirements is a process that can help customers reduce costs and still get the system they want. • The basic idea is that there may be existing components that meet the customer’s essential requirements, but might not meet all requirements stated initially. • The process requires an existing trust relationship with the customer. • Systems engineering costs are high! Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 35

Use-Cases in Requirements Engineering Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 36

Web Crawler Example • The next two diagrams illustrate a simple example of how an administrator would interact with a web crawler to gather information from a collection of websites in order to provide for later analysis. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 37

Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 38

Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 39

Use-Cases • Additional ones may be necessary for most systems – Including the major continuing software development project Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 40

Usability Requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 41

Bleser’s Guidelines • Identify relevant guidelines. • From the overall set of guidelines, select those that pertain to the application. • Narrow down the subset of pertinent guidelines. • Develop design rules from the guidelines. • Allow for reasonable exceptions. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 42

A few more detailed guidelines • Identify the attributes of user performance that may be affected by the conflicting guidelines (e. g. , color discrimination, target detection, speed of response). • Weight the importance of those attributes for overall system performance for this project. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 43

A few more detailed guidelines • Using a numeric scale, rate the conflicting guidelines for their expected effect on each performance outcome. • Multiply ratings by weights and sum the products. Select the guideline with the higher total. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 44

Specifying Requirements by State Diagrams Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 45

Chemical Reaction State Diagram Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 46

State Table Function Current State Input New State 1 B 2 2 250 3 3 R 4 4 300 5 5 H 5 5 300 7 5 anything else 6 6 250 5 7 anything but 400 8 7 400 9 8 P 9 8 S 1 9 Anything 9 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 47

State Diagram Decision Table Current State Input New State 1 B 2 2 if temp <= 250 3 3 R 4 4 if temp >= 300 5 5 H 5 5 if temp >= 300 7 5 if temp >= 400 9 5 anything else 6 6 if temp <= 250 5 7 anything but temp >= 400 8 7 if temp >= 400 9 8 P 9 8 S 1 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 48

Ethical Analysis of Requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 49

Ethical Issue- Requirements are incorrect • Some computations are theoretically impossible. • Some interactions with different subsystems are inconsistent within the software itself. • Some interactions are inconsistent with systems intended to be interoperable. • Impossible performance demands – execution time or space requirements. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 50

IEEE Code of Ethics (excerpt) • To accept responsibility in making engineering decisions consistent with the safety, health, and welfare of the public, and to disclose promptly factors that might endanger the public or the environment; • to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they exist; Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 51

IEEE Code of Ethics (excerpt) • to be honest and realistic in stating claims or estimates based on available data; • to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations; Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 52

IEEE Code of Ethics (excerpt) • to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit promptly the contributions of others; Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 53

What if you bring suspected problems to a manager? • The manager does not agree with your analysis. • The manager agrees with your analysis and will ask the requirements team to fix the problem. • The manager seems to be ignoring the problem, allowing a potentially serious problem to occur. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 54

Specifying Requirements Using Petri Nets for Concurrency Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 55

Transitions fire when there are tokens in each input place Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 56

Metrics for Requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 57

Some Approaches • Count the number of distinct requirements. • Compute the sum over all requirements of the “functionality” of each requirement. • Matching the requirements to those of existing systems that are to be reused. • Compute the “size” of the interfaces to other software systems to which the desired software will be interoperable. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 58

Function Points (Albrecht) • The number and type of user interactions. • The number and type of interfaces to internal files. • The number and type of interfaces to external files. • The general perception of the difficulty of programming in the application domain. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 59

Weights for Function Points External input or files External outputs or reports External queries or responses External interfaces to other systems Internal files Simple 3 Average 4 Complex 6 4 5 7 3 4 6 7 10 15 5 7 10 Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 60

Use this table for FPs FP = count_total *(0. 65 + sumf. I /100) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 61

Another metric • How many requirements can be met by simply reusing a large-scale component or COTS product? – Remember that reuse of requirements and related designs, code, test plans, etc. has the highest payoff in reducing cost and effort Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 62

The Requirements Review Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 63

Checklist for a Requirements Review Meeting Presentation rehearsed. Time of presentation within allotted limits. Sufficient time is available for questions. People who can answer technical questions are in attendance. • Slides, transparencies, and multimedia materials checked for accuracy and spelling. • • Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 64

Checklist for a Requirements Review Meeting • Copies of slides and multimedia materials available to all participants. • Meeting room has all necessary equipment • Network connectivity needed to control presentation (including Bluetooth, infrared, and ad-hoc networks) available. • An attendance list with contact information. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 65

Requirements – Waterfall model • Requirements should be complete, consistent, and free of any ambiguities. • The software design process should be ready to begin. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 66

Requirements – Iterative models • The next iteration should be able to continue without delay. • Requirements should be consistent and free of any ambiguities. • Any incompleteness should be resolvable in the next iteration. • Requirements should be more complete than at the end of the previous iteration. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 67

Requirements – Iterative models, cont. • A software project manager wants his or her project to produce software to be developed efficiently and the final product to be of high quality. • Some inefficiency or detours during the setting of requirements and the system’s design are probably unavoidable. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 68

Requirements – Iterative models, cont. Managers hate unexpected surprises. – Incoherent requirements review presentations. – Missing documentation. – Obvious omissions. – Customer angry because technical and other issues raised earlier meetings were ignored. – Logistical infrastructure, AV, too small room. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 69

Management Perspectives on Requirements Reviews • Relative certainty that the software will be developed efficiently and the final product will be of high quality. • Some inefficiencies or detours during the setting of requirements and the system’s design are probably unavoidable. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 70

Managers hate unexpected surprises Incoherent requirements review presentations. Missing documentation. Obvious omissions. Angry customer because issues raised at an earlier meeting were ignored. • Missing logistical infrastructure • • – audio-visual equipment or a too small room. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 71

Case Study of Management Perspective on Requirements in Agile Development Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 72

Case Study Context • Experienced team in the domain of spacecraft control systems • Most of the team had won an award for cost savings, even while producing software of very high quality Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 73

Fundamental Assumptions • The team is experienced in the application domain and buys in to agile processes • The team is talented • Team members can work independently • The team knows the capability and quality of available large-scale components and COTS products • Management support using agile processes Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 74

Team attitudes • Avoided the “Not Invented Here Syndrome” • Attitude projected was more of “I can't tell you what I want, but I'll let you know when you get there!” Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 75

The Requirements • Started out vague and broadly focused • Selected a COTS product, Lab. View, to control software – Lab. View normally used to control experiments – Lab. View had an international user base and was unlikely to be discontinued • Applied agile techniques to a large set of systems Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 76

Experience allowed decreased time to gather requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 77

The Major Continuing Software Development Project - Requirements Elicitation Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 78

Requirements Elicitation • Several stakeholders develop a problem statement after several iterations. • Eliminate vague and unsustainable words – Standard, as simple as possible, flexible enough, should have a common interface, treated as library requirements • They produce some examples of how the system should work. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 79

Requirements Traceability • Create a preliminary RTM. • If no test can be determined for a particular requirement, it should be rewritten or discarded. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 80

Sample designs of screens Such mockups can help explain proposed systems Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 81

Review • Review the requirements Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 82