1. www.ischool.drexel.edu INFO 425 Week 21 INFO 425 Design Problem I Week 2 – SRS Improvements Glenn Booker

2. www.ischool.drexel.edu INFO 425 Week 22 SRS Improvement These notes focus on common improvements needed for your requirements documents –See also the notes from INFO 424, week 3 Everything else (test spec, design, implementation) depends on having coherent, clear requirements!

3. www.ischool.drexel.edu Requirements build In the SRS, section 1.2 is a short overview of your product –This is the “elevator talk” to describe your system, product, or project Section 2.2 builds and expands on that –This is a bulleted list of major types of functionality your product will achieve –Like you’d see on product packaging INFO 425 Week 23

4. www.ischool.drexel.edu Requirements build The detailed requirements for your system are in section 3 All the detailed functional requirements are in section 3.2 –So this section should be substantial! –Within 3.2 you have the choice of breaking requirements down by use cases, or by subsystem, or by type of functionality, etc. INFO 425 Week 24

5. www.ischool.drexel.edu Non-functional requirements The detailed non-functional requirements are in two places Section 3.3 for performance requirements –This could include speed, capacity (# users) Section 3.6 for all other non-functional requirements –Usability, reliability, availability, security, etc. INFO 425 Week 25

6. www.ischool.drexel.edu Identify requirements Within the detailed requirements (sections 3.2, 3.3, and 3.6) EVERY requirement should have three things –An identifier; could be its own paragraph number, or some letter and number combination (F012 for functional requirement 12, or S013 for server requirement 13, etc.) –A short phrase to summarize it –A concise description (1-2 sentences) INFO 425 Week 26

7. www.ischool.drexel.edu Identify requirements The phrases should be only a few words, and usually verb-first (Generate monthly sales report, Add system user) like use case names Descriptions should include who primarily needs that requirement (end user, manager, sys admin, all users, etc.), and what external systems are involved if any (e.g. Google Maps) INFO 425 Week 27

8. www.ischool.drexel.edu Identify requirements This approach gives you an easy way to cite requirements, for example in the test specification And yes, non-functional requirements need individual identifiers too –How else will you test them? INFO 425 Week 28

9. www.ischool.drexel.edu Use case diagram If you use ‘use cases’ for describing functional requirements in section 3.2 there should be a use case diagram –Actors (types of users) are represented by labeled stick figures –Lines connect actors to use cases they may use –Use cases are each in an oval –Show a system boundary rectangle with the name of your system INFO 425 Week 29

10. www.ischool.drexel.edu Use case diagram The diagram should also show external systems you need (if any) Actors and external systems are outside the system boundary, please –Otherwise lawsuits or TRON3 could ensue INFO 425 Week 210

11. www.ischool.drexel.edu Use cases Name each use case with a verb-first short name, and number the use cases, e.g. –1. Create new user –2. Modify existing user Then describe each use case, in numeric order, in a couple of sentences –Go into more detail for use cases you’re implementing in cycle 1 INFO 425 Week 211

12. www.ischool.drexel.edu General SRS notes Section 1.1 is the purpose of the SRS, not of the system See last week’s notes for comments about references (section 1.4) –At least cite your Launch report Section 1.5 is an overview of the SRS document; again, not your product INFO 425 Week 212

13. www.ischool.drexel.edu General SRS notes Section 2.3 identifies the users of your system –Should match the types of actors in your use case diagram, or the roles discussed in detailed requirements Section 2.4 describes constraints, which generally come from your customer –Don’t add requirements here! INFO 425 Week 213

14. www.ischool.drexel.edu General SRS notes Section 2.6 identifies what functionality you’ll implement in the three cycles –It’s okay if this changes later, but try to be both realistic and a little ambitious Section 3.1.1 only applies only if your system talks to external systems Section 3.1.2 is not your GUI design! –Just general interface guidelines INFO 425 Week 214

15. www.ischool.drexel.edu General SRS notes Section 3.4 is NOT an ERD –Describe data requirements in practical business terms, not data structures or GB “The system shall be able to store data from 10,000 customers and 500,000 orders.” For another example, your iSchool advisors have to keep all emails from students. Forever. INFO 425 Week 215

16. www.ischool.drexel.edu General SRS notes Sections 3.5 (Design Constraints) and 3.7 (Software System Attributes) probably don’t apply, so just say so Don’t get suckered into designing your system here! INFO 425 Week 216

17. www.ischool.drexel.edu General SRS notes Section 3.6 (Standards Compliance) could include customer-mandated requirements for following –Process or quality standards (ISO 9000, CMMI, etc.) –Industry or legal standards (HIPAA, ITIL, JCAHO, FOIA, etc.) –Not interface standards (Windows or Mac) (should appear under usability requirements) INFO 425 Week 217

18. www.ischool.drexel.edu Test Specification The test specification is a simple document in structure Show how all requirements are verified –Including functional requirements, non-functional requirements, and design constraints See INFO 424 week 3 for details –/can’t think of anything to add INFO 425 Week 218