1. www.ischool.drexel.edu INFO 424 Team Project Practicum Week 3 – Software Requirements Specification Glenn Booker Notes mostly from Prof. Hislop and INFO 627 lectures 6 to 9 1INFO 424 Week 3

2. www.ischool.drexel.edu Agenda Software Requirements Specification and Test Specification Remember that your system may ultimately involve non-software such as: –Hardware –Users –Training –Documentation, etc. 2INFO 424 Week 3

3. www.ischool.drexel.edu Requirements Requirements need to be: –Understood by all parties concerned –Specific enough to be verified and demonstrated From the beginning, think of requirements in terms of being able to prove whether they have been fulfilled (“Trust but verify”) 3INFO 424 Week 3

4. www.ischool.drexel.edu Software Requirements Think of the system as a black box, and focus on what needs to go into and leave the system Five major classes of things can describe a system –Inputs to the system, in terms of content, format, and source 4INFO 424 Week 3

5. www.ischool.drexel.edu Software Requirements –Outputs from the system, including the type of output device, and format of the outputs –Functions of the system, to accept inputs and/or create outputs –Attributes of the system, such as the “–ilities”, throughput, and performance –Attributes of the system environment, such as where it is used, and compatibility with other systems 5INFO 424 Week 3

6. www.ischool.drexel.edu What Requirements Are Not The challenge in writing requirements is to avoid things which shouldn’t impersonate requirements –Project management information –Unneeded design or implementation details –Testing information Requirements should focus on system behavior, not its inner workings 6INFO 424 Week 3

7. www.ischool.drexel.edu Project Management Information Requirements should not include –Budget, staffing, or schedule information –Configuration management plans –Testing plans (except maybe hints for very unusual cases) Put these in separate Program Management Plan, CM Plan, etc. 7INFO 424 Week 3

8. www.ischool.drexel.edu Requirements Gathering Draft system concept description and share with user What are the current processes? (if any) What is the problem to be addressed? –Top 5 functions What are the goals –Why is this system needed? 8INFO 424 Week 3

9. www.ischool.drexel.edu Requirements Gathering What are the key data concepts? What is the scope of the product? What non-functional requirements are there? What constraints are there (e.g. customer- mandated technology choices) Who are the key actors? –Are there stakeholders who aren’t actors? 9INFO 424 Week 3

10. www.ischool.drexel.edu Software Requirements Specification (SRS) Sources –Document template on course site –IEEE std. 830-1998 you download –Prior course work and texts Key points –User oriented document Write so users could read it and understand –Not a design or project management document Do NOT make design decision or assumptions here –Represents the agreement between developers and client as to what the product will do 10INFO 424 Week 3

11. www.ischool.drexel.edu Sample requirements? The system shall have the ability to generate ad-hoc reports. The system shall be client/server based. The system shall have a user-friendly interface. The system shall have the capability of remote user access through a Web Browser with query and reference copy functions, as a minimum. The system shall have the ability to cancel active documents. From an FAA RFI for a document management systemFAA RFI 11INFO 424 Week 3

12. www.ischool.drexel.edu Sample requirements? –The system shall have the ability to manage concurrent revisions. –The system shall have the ability to copy drawings for reference. –The system shall have the ability to submit drawings for approval. –The system shall have the ability to edit metadata. –The system shall have the ability to create multiple workflows. 12INFO 424 Week 3

13. www.ischool.drexel.edu Sample requirements? –The system shall have E-mail messaging compliant with SMTP (UNIX) and MAPI (Windows). –The system shall have the ability to handle long filenames with 32 characters or greater. –The system shall have the ability to perform text searches within documents. –The system shall have the ability to generate and store custom reports. 13INFO 424 Week 3

14. www.ischool.drexel.edu SRS Section 1 is the Introduction –Notice that 1.1 pertains to the SRS document, not your system or product Section 2 is a brief description of your system –2.1 describes the general features of your system; what kinds of things can a user do with it? –2.2 describes the users of your system 14INFO 424 Week 3

15. www.ischool.drexel.edu SRS Section 3 is the main body of the document –3.1 is the main breakdown of functional requirements for your system Give each requirements an identifier (e.g. paragraph number or P001) and brief name (Generate weekly sales report) Input and output descriptions may be added when helpful 15INFO 424 Week 3

16. www.ischool.drexel.edu Writing the Requirement Action –List each action that the system must be able to perform –Write this part first (then add the input and output) –Use complete sentences –“The system shall…” Input and Output –Optional – don’t just repeat the Action 16INFO 424 Week 3

17. www.ischool.drexel.edu Writing the Requirement Input (optional) –What causes the Action to happen? Must be something detectable within the software –What data or state is needed for the action to occur? Output (optional) –What is the result of the Action? State changes Data changes 17INFO 424 Week 3

18. www.ischool.drexel.edu SRS Use a prefix in the identifier to indicate how you’re breaking down requirements –By user or actor (C = Clerk, VP = VP, etc.) –By system component (W = Web interface, WS= Web Server, DS = Database server...) –By use case number (UC001) –Or by some other convention (specify!) Describe the Action required for each requirement 18INFO 424 Week 3

19. www.ischool.drexel.edu Requirement Quality Simply having defined the requirements is a good start Beyond that, quality for each requirement or specification has nine aspects –Correct: meets needs of user –Unambiguous: only has one interpretation –Complete: meets all needs and conditions –Consistent: with other requirements 19INFO 424 Week 3

20. www.ischool.drexel.edu Requirement Quality –Ranked: for importance or priority –Verifiable: often by testing –Modifiable: to allow for requirements changes –Traceable: to needs or later design –Understandable Most of these came from IEEE 830 20INFO 424 Week 3

21. www.ischool.drexel.edu Software Requirements Specification (SRS) 3.2 – Non-Functional requirements –Write carefully and use complete sentences Start with the Action –Match requirement label to content –Define data concepts and groups; name them and use names for Input and Outputs 21INFO 424 Week 3

22. www.ischool.drexel.edu Non-Functional Requirements Consider what nonfunctional requirements are relevant for your system, such as –Usability Time needed for training Time to perform task Usability compared to other systems Availability of help Compliance with HCI standards (Windows, Mac)WindowsMac 22INFO 424 Week 3

23. www.ischool.drexel.edu Non-Functional Requirements –Reliability Availability (%) Mean time between failures (MTBF, hours) Mean time to repair (MTTR, hours) Accuracy (numeric precision, number of decimals) Defect rate (defects/1000 lines of code) Bugs per type (number of bugs by severity) 23INFO 424 Week 3

24. www.ischool.drexel.edu Non-Functional Requirements –Supportability Expected implementation time for minor, medium, and major enhancements Planned or possible future enhancements mostly affect design decisions –Most other ‘-ilities’ are nonfunctional requirements Portability (to other platforms) Maintainability Etc. 24INFO 424 Week 3

25. www.ischool.drexel.edu Performance Requirements Performance requirements could include –Response time for a transaction – average, maximum, some % below some value (e.g. 95% below 5 sec response time) –Throughput (transactions per second) –Capacity (number of simultaneous users) –Degraded modes of operation (what are performance expectations if system is partially offline) 25INFO 424 Week 3

26. www.ischool.drexel.edu SRS Section 3.3 is an outline of major data concepts –Don’t try to do a full ERD here or include keys –What major categories of data will your system need to manage? Section 3.4 has design constraints –Don’t make up some just to avoid a blank section, say ‘This system has no design constraints’ instead 26INFO 424 Week 3

27. www.ischool.drexel.edu Design Constraints We generally want to define requirements so that several design approaches might be used to implement them Constraints might be imposed by the customer such as the development language, use of corporate reuse libraries, coding standards, or external standards such as FDA, DOD or FCC regulations 27INFO 424 Week 3

28. www.ischool.drexel.edu Design Constraints Should distinguish constraints from requirements, such as using a “DC” prefix, and isolate them from the true requirements Identify the source of each constraint, and why it was imposed (if known) 28INFO 424 Week 3

29. www.ischool.drexel.edu Use Cases If you’re using use cases in section 3.1 to capture functional requirements, include a use case diagram Hints for the use case diagram: –Actors are clearly labeled stick figures –External systems can be labeled boxes –System boundary is labeled with your system’s name on it 29INFO 424 Week 3

30. www.ischool.drexel.edu Use Cases –System boundary doesn’t enclose actors or external systems –Lines connect actors to the use cases they can perform –Generalization can be used to simplify the diagram –‘Included’ use cases must be used by at least two other use cases 30INFO 424 Week 3

31. www.ischool.drexel.edu Use Cases Name use cases in verb-adjective-noun format, e.g. Modify existing customer, Generate sales report, Delete user, etc. Omit trivial use cases, e.g. log in and log out Number use cases, and provide documentation of each following that number sequence 31INFO 424 Week 3

32. www.ischool.drexel.edu Use Case documentation For use cases you are implementing this cycle, documentation should include: –Use case number and name –Primary actor –Main success scenario –Alternative scenarios (Extensions) –Typical time to execute use case –Frequency use case will be performed x times per day or week or whatever 32INFO 424 Week 3

33. www.ischool.drexel.edu Use Case documentation For all other use cases, document them with: –Use case number and name –Primary actor –A brief narrative description of the main success scenario (1-3 sentences) 33INFO 424 Week 3

34. www.ischool.drexel.edu Functional Requirements Functional requirements may be organized (IEEE 830, App. A) by: –Mode of operation of the system; best used for software-intensive mechanical systems, each mode’s functional requirements are detailed (scanning mode, editing mode, acquisition mode, etc.) If needed, each mode’s interfaces, functional, and performance requirements can be addressed 34INFO 424 Week 3

35. www.ischool.drexel.edu Functional Requirements –User class; where each type of user of the system has well defined activities they must perform, then their functional requirements are listed –Class; for object oriented systems; each class is described in terms of its attributes, methods, and messages 35INFO 424 Week 3

36. www.ischool.drexel.edu Functional Requirements –Feature; similar to use case descriptions, identify when and how each feature is to be used, and the functional requirements for each feature –Stimulus; useful when the system’s responses (functional requirements) are based on what kind of specific stimulus or message it receives 36INFO 424 Week 3

37. www.ischool.drexel.edu Functional Requirements –Functional hierarchy; break the requirements down by information flow, process, or data construct, and provide a data dictionary to specify each data element’s format; good for reengineering legacy information systems –Or any combination of the above methods (multiple organizations), such as mixing user class then stimulus and response 37INFO 424 Week 3

38. www.ischool.drexel.edu Balancing Requirements We need to review requirements for –Consistent level of detail throughout the system –Adequate level of detail to guide implementation, without over constraining that implementation Most of the SRS is text –Graphics can be helpful but beware of adding implied design 38INFO 424 Week 3