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

INFO 425
Design Problem I
Week 2 – SRS Improvements
Glenn Booker
INFO 425 Week 2
1
www.ischool.drexel.edu
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!
INFO 425 Week 2
2
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
www.ischool.drexel.edu