www.ischool.drexel.edu info 425 week 21 info 425 design problem i week 2 – srs improvements glenn...
TRANSCRIPT
www.ischool.drexel.eduINFO 425 Week 2 1
INFO 425Design Problem I
Week 2 – SRS Improvements
Glenn Booker
www.ischool.drexel.eduINFO 425 Week 2 2
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!
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 2 3
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 2 4
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 2 5
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 2 6
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 2 7
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 2 8
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 2 9
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 2 10
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 2 11
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 2 12
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 2 13
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 2 14
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 2 15
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 2 16
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 2 17
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 2 18