1. Requirements 101
CS3300
Fall 2015

2. Requirements Discipline
Elicitation
Analysis
Specification
Validation
Control
Traceability

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

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

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

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

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

8. More Examples
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.
Each user id must be unique.
The report shall display information such as name, ssn, and amount due.

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

10. 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?)

11. 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) ( )

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

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

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

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

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

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

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

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

20. Validation
Requirements Review Prototype Use Case Walkthrough Acceptance Tests Model Validation

21. Control
Gold-Plating Feature Creep Bad – Just code the changes, add scenarios as you discover them Good – Add them to product backlog

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