Requirements 101 CS3300 Fall 2015

Requirements Discipline Elicitation Analysis Specification Validation Control Traceability

Definition A property or behavior that a software system must have to solve a particular problem. Functional and Non-Functional Requirements Characteristics: Correct, Complete, Unambiguous, Testable, Consistent

Requirements are what the system has to do NOT how it will do it. Most Important Idea Requirements are what the system has to do NOT how it will do it.

Key words Shall, Must – some the system is required to do Should – a preferred but optional feature May – a nice to have feature You have to do all the “shalls”. The more of the “shoulds” that you can do, the more happiness you give the customer. “Mays” usually are customer suggestions, but you don't have to follow them.

Quality Function Deployment Ideas Normal Requirements – objectives stated by customer Expected Requirements – implicit to the product (ease of use, ease of installation) Exciting Requirements – exceeding the customer expectations

Some Examples, are they good or bad? 4.1.3 The software shall be easy to use. 3.1.1.2 The quarterly report view shall show the total sales for the quarter in a prominent place. 3.3.2.1 User login shall be accomplished in no more than 1 second.

More Examples 3.2.1.4 The software shall enforce a user id format of 4-8 characters, one of which must be a letter, at least one must be a symbol and at least one must be a digit. 3.2.1.5 Each user id must be unique. 3.5.4.1.1.1 The report shall display information such as name, ssn, and amount due.

Your turn Write one good requirement for t-square. There is a piazza thread for you to enter.

Non-Functional Requirements Performance (Are there constraints on speed, memory usage, etc) Reliability (Mean Time Between Failure) Availability (What is required up time?) Portability (What platforms does this have to run on?) Interoperability (What other systems do you need to play nice with?) Accuracy (What precision does data need?)

More NFR's Maintainability (Special constraints on operating the system) Extensibility (Run time modification of the system – like Eclipse plug-in system) Expandability (Add new features, hooks and design) Safety (Fault tolerance and hazard analysis) Security (threat models and analysis) ( http://www.sans.org/top25-software-errors/ )

Big Problem Getting good requirements is HARD Thus was invented numerous techniques beyond the basic interview / survey / observation / document review Conflict resolution is also a major issue Identifying hidden affordances and work processes

Techniques Joint Applications Development (IBM 77-84) Contextual Design (Holtzblatt and Beyer 98) Win Win (Boehm 98)

JAD Capers Jones states, "A study of over 60 projects ... showed that those projects that did not use JAD missed up to 35% of required functionality resulting in the need for up to 50% more code." The Capers Jones study determined that projects that used JAD missed only 5 percent to 10 percent of required functionality with minimal impact on the code. ·David Freedman states, "How do you design a system that users really want? ... You can't. What you can do is help users design the systems they want." ·"The successful use of JAD has pushed its use beyond traditional applications of the process. JAD is being used successfully for strategic systems and data planning, as well as for projects outside the IS community."—General Electric

Contextual Design Assumptions Challenge of design is to fit system into everyday life – be non-intrusive Social aspects are as important as technical aspects Systems impose a model of work on the users Good design = optimal match between user's desired way of doing work and the model imposed by the system. Design depends on seeing implications of data System is more important than individual features

Design Models Flow Diagram – Communication and Coordination necessary to do the work Sequence Model – Detailed work steps to achieve an intent Artifact Model – Physical things created to support work Cultural Model – Constraints on work due to policy, culture or values Physical Model – Physical structure of the work environment and it affects the work. Consolidated Models All the above plus Affinity Diagram – Pull key concepts out of other models, group together by similarity

Theories of Management Theory X – Employees are basically lazy, require close supervision Theory Y – Employees want to do the right thing, managers just have to provide environment, can cause conflicts Theory Z – Increase loyalty by providing stable enviroment, focus on employee well-being, build shared values to reduce conflict

Win Win Theory W – figure out win conditions of employees and meet them. What are the win conditions of stakeholders? How can we make everyone win? Boehm Paper in readings Resolve conflicts

Specification The SDS - oriented to the users The SRS – oriented to the developers See format in resources

Validation Requirements Review Prototype Use Case Walkthrough Acceptance Tests Model Validation

Control Gold-Plating Feature Creep Bad – Just code the changes, add scenarios as you discover them Good – Add them to product backlog http://www.stevemcconnell.com/rdenum.htm 28-32

Traceability Every requirement is identified (usually with a unique paragraph number like 3.1.4.3) Every requirement has a traceable source (where it came from).