1 Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder Needs (8-13) Team Skill 3 – Defining the System (14-17) Team Skill 4 – Managing Scope (18-19) Team Skill 5 – Refining the System Definition ( 20-24) Team Skill 6 – Building the Right System (25-31)

2 Software Requirements – A More Rigorous Look Chapter 20

3 Five Major Classes of Things Inputs to the system  Contents of the inputs  Details of input devices Outputs from the system  Description of output devices  Protocol and formats of information generated by the system Functions of the system  Mapping inputs to outputs and combinations Attributes of the system  Typical non-behavioral requirements (ilities) Attributes of the system environment  Ability to operate with other systems

4 Looking Deeper into Software Requirements Relationship between requirements and use cases  Use cases are just one way to express software requirements Relationship between features and requirements  Direct relationship and requirements are more specific than features What versus How  Requirements tell us what the system must do  Requirements should not tell how or contain any unnecessary design Exclude project information  Project information (schedule, CM plans, budgets, etc. ) are managed differently and should not be part of the requirements

5 Iterating Requirements and Design Requirements discovery, definition, and design decision are circular Current requirements cause us to consider selecting certain design options, Selected design options may initiate new requirements and

6 Three Types of Requirements Functional  Express how the system behaves  Inputs, outputs, and functions it provides to its users  Captured in use cases Nonfunctional  Attributes of the system or system environment  “ilities” Design constraints  Impose limits on the design of the system  Definition: restrictions on the design of a system, or the process by which a system is developed, that do not affect that external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations

7 Key Points A complete set of requirements can be determined by defining the inputs, outputs, functions, and attributes of the system plus the attributes of the system environment Requirements should exclude project-related information, such as schedules, project plans, budgets, and tests, as well as design information The requirements/design process is iterative; requirements lead to the selection of certain design options, which in turn may initiate new requirements Design constraints are restrictions on the design of the system or on the process by which a system is developed

8 Refining the Use Cases Chapter 21

9 Anatomy of a Use Case Review actors  Identify not only the initiating actors but those impacted as well Review the name  No two use cases can have the same name  The use case should begin with an action verb Refine description  Make any adjustment based on the actors or name updates Refine flow of events  Look for other alternate paths and error conditions Identify pre- and post-conditions  These conditions should be one that the users can observe

10 Extending Use Cases Used to add functionality for a later release Simplifies maintenance of the use case and allows the team to focus on the extension Extension points can be provided in the base use case to map functionality The extended use case can represent optional behavior Control Light Update Display Indicator «extends» If some of the HOLIS systems included an optional “light bar” indicator on the Control Switch, then an extended use case could extend the behavior of the base Control Light use case

11 Including Use Cases Used with patterns of user and system behavior reoccur in a variety of places Reduces maintenance, when a change occurs, it only needs to be documented in the included use case and not all the places the Common behavior takes place

12 Key Points To support development and testing activities, the use cases defined earlier in the project must be more fully elaborated The use-case model is reviewed and will often be refactored as well A well-elaborated use case also defines all alternative flows, pre- and post-conditions, and special requirements The additional use-case relationships extend and include help the team structure and maintain the use-case model

13 Developing the Supplementary Specification Chapter 22

14 Nonfunctional Requirements Usability – ease of use  Specify the required training time for a use to become minimally productive  Specify measurable task time for typical tasks or transactions Time to place a typical order  Compare usability to another commonly known system “The system shall be judged by 90% of the users to be at least as usable as the existing XYZ system”  Specify required features of online help systems, tool tips, context-sensitive help, etc.  Follow conventions and standards that have been developed for human-to-machine interface IBM’s Common User Access (CUA) standards

15 Nonfunctional Requirements Reliability  Availability – System must be available X.XXX% between hours of 7am and midnight.  Mean time between failures (MTFB) – usually specified in hours  Mean time to repair (MTTR) – how long system can be out of operation after a failure  Accuracy – what precision is required in numerical outputs  Maximum bugs, or defect rate – bugs/KLOC  Bugs per type – usually categorized in terms of minor, significant, and critical

16 Nonfunctional Requirements Performance  Response time for a transaction  Throughput: transactions per second  Capacity: number of customers or transactions the system can handle  Degradation modes: the acceptable mode of operations when the system has been degraded  Memory, storage and bandwidth

17 Nonfunctional Requirements Supportability  Ability of the software to be easily modified to accommodate enhancements and repairs  Could stipulate response time of the maintenance group from simple enhancements, moderate enhancements, and complex enhancements  Where a system is known to have future modifications…how fast these modification can be made  This could get into design constraints and start to require a DBMS or programming styles and standards like run-time binding

18 Design Constraints Three sources  Restriction of design options  Conditions imposed on the development process  Regulations and imposed standards Handling design constraints  Distinguish them from other requirements, use a tag  Include all design constraints in a special section of the requirements document  Identify the source of each design constraint  Document the rationale of each design constraint

19 Linking the Supplementary Specification to the Use Cases Define certain classes of nonfunctional requirements, then link each class to a use case For example: classes of response time may be  Class 1: 0 to 250 millisecs  Class 2: 251 to 499 milisecs  Class 3: 0.5 to 2 secs  Class 4: 2.1 to 12 secs  Class 5: 12.1 secs to 60 mins Use Case A might record  Class 2 for main flow events and Class 4 for all exceptions While Use Case B might record  Class 5

20 Supplementary Specification Template Page 268 of text

21 On Ambiguity and Specificity Chapter 23

22 Light Box Exercise OnOff Power Count EvenOdd Features Microprocessor Controlled Keeps track of whether count button has been pressed an even or odd number of times Burned-out-bulb detector flashes remaining bulb Requirements After On pushed but before Off pushed, system is termed “powered on” After Off pushed but before On pushed, system is termed “powered off”, and no lights shall be lit Since most recent On press, if Count has been pressed an odd number of times, Odd shall be lit Since most recent On press, if Count has been pressed an even number of times, Even shall be lit If either light burns out, the other light shall flash every 1 sec

23 Light Box Exercise Off On Duty Cycle A Duty Cycle B Which duty cycle does the requirement want?

24 Key Points The requirements “sweet spot” is the balance point of the greatest amount of understandability and the least amount of ambiguity A learned skill, finding the sweet spot will depend on the team members’ abilities, the application context, and the level of certainty you must provide so that your system works as intended If the risk of misunderstanding is unacceptable, more formal requirements techniques may need to be applied Always include a glossary

25 Technical Methods for Specifying Requirements Chapter 24

26 Pseudocode A “quasi” programming language A combination of the informality of natural language with the strict syntax and control structure of a programming language Should be possible for a nonprogramming person to understand The algorithm for calculating deferred-service revenue earned for any month is: Set SUM(X)=0 FOR each customer X IF customer purchased paid support AND ((Current month) >= (2 months after ship date)) AND ((Current month) <= (14 months after ship date)) THEN Sum(X)=Sum(X) + (amount customer paid)/12 END

27 Finite State Machines State transition diagram Even lit Odd litOdd lit/LOUT Even lit/LOUT Off Light burned out Count 1 sec off on

28 Finite State Machines StateOn Press Off Press Count Press Bulb Burns Out Every Second Output OffEven lit LO/Odd lit LO/Even lit Both off Even litOffOdd litLO/Even lit Even lit Odd litOffEven litLO/Odd litOdd lit Light out Even lit Off Even lit Light out Odd lit Off Odd lit

29 Decision Tree for HOLIS Emergency Sequence Has emergency sequence occurred? Is remote notification enabled? Initiate emergency message Did remote security respond? Do nothing Activate siren Do nothing Is local alarm enabled? Do nothing Yes No

30 Activity Diagrams Get req ref from doc Get text ref from doc Remove req from DB Remove req from Doc [no more] [more] [empty] [not empty] Activity diagrams are a nuisance to keep up-to-date

31 Entity-Relationship Model Description of the structure and relationships among data within the system Provides a high-level architectural view of the data Must take time to learn the notation – a disadvantage Example on page 285

32 Key Points Technical methods for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood Technical methods include pseudocode, finite state machines, decision trees, activity diagrams, entity- relationship models, and many others