Www.ischool.drexel.edu INFO 424 Team Project Practicum Week 3 – Software Requirements...

www.ischool.drexel.edu

INFO 424Team 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


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


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


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


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


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


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


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


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


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


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 system

11INFO 424 Week 3



– 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



– 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


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


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


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


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


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


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


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


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


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)

22INFO 424 Week 3



– 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



– 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


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


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


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


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


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


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


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


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 whatever32INFO 424 Week 3


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


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



– 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



– 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



– 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


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

Www.ischool.drexel.edu INFO 424 Team Project Practicum Week 3 – Software Requirements...

Documents

Transcript of Www.ischool.drexel.edu INFO 424 Team Project Practicum Week 3 – Software Requirements...