System and Software Requirements Defintion SSRD

1
System and Software Requirements Defintion (SSRD)
Dr. Barry Boehm USC-CSEDr. Dan Port
USC-CSEDavid Klappholz StevensCS577aFall 2002

• Enhanced by Jim Alstad, USC, 2003

2
Introducing Jim

• Worked for 27 years in software
• Last 22 at a company which practices software
  engineering
• Now doing satellite software for Boeing Satellite
  Systems
• Have formal education in the field
• BS in Computer Sciences, 1973
• Master of Software Engineering, 1991
• Have moonlighted as teacher for 16 years
• For Winsor Brown, substitute teaching CS 511
• For Ed Colbert, teaching Ada and OO methods
• Interests include software architecture,
  technical processes, formal methods,
  professionalism

3
Jims One-Word Summaries of Operational Concept
Description (OCD),System and Software
Requirements Definition (SSRD),System and
Software Architecture Defintion (SSAD)
4
Essential Questions Answered by OCD, SSRD, SSAD
OCD
Why?
What are the purposes that the client intends for
the system?
SSRD
What?
What are the system properties which can satisfy
those purposes?
SSAD
How?
What are the implementation structures which can
provide those properties?
2. System Analysis
5
System and Software Requirements Definition (SSRD)
6
Purpose of SSRD

• Describe capability requirements (both nominal
  and off-nominal) i.e., the fundamental subject
  matter of the system, measured by concrete means
  like data values, decision-making logic and
  algorithms.
• Describe Level of Service Requirements (sometimes
  referred to as Non-functional requirements)
  i.e., the behavioral properties that the
  specified functions must have, such as
  performance, usability, etc. Level of Service
  Requirements should be assigned a unit of
  measurement.
• Describe global constraints requirements and
  constraints that apply to the system as a whole.
  For example, the customer for the system is a
  global constraint, as is the Purpose of the
  System. Those constraints include Interface
  Requirements, Budget and Schedule Requirements,
  Implementation Requirements
• Mandates and instructions on how the system must
  be implemented ("must", "shall", "will"), with
  respect to the general technology
• Commitment addressing WinWin agreements,
  policies, constraints

7
SSRD Purpose in MBASE

• Life cycle objective
• Top-level functions, interfaces, quality
  attribute levels, including
• Growth vectors
• Priorities
• Traces to OCD
• Especially 4.3 (System Capabilities), 4.4 (LOS
  Goals)
• Stakeholders concurrence on essentials

• Life cycle architecture
• Elaboration of functions, interfaces, quality
  attributes by iteration
• Resolution of TBDs (to-be-determined items)
• Stakeholders concurrence on their priority
  concerns (prioritization)
• Traces to SSAD (and indirectly to FRD, LCP)

8
Overall Description

• Intended audience
• Implementers
• Domain expert (decision makers) for system
  definition
• No architecture descriptions those belong to the
  SSAD
• Participants
• Same stakeholders as WinWin negotiation

9
Dependencies

• SSRD depends on WinWin taxonomy
• Outline of SSRD evolves from taxonomy
• There is no one-size-fits-all taxonomy or
  requirements description
• Importance of adapting taxonomy to domain
• Agreed upon Win conditions and priorities become
  requirements
• Options describe how for requirements.
• SSRD depends on OCD
• Statement of Purpose
• Project Goals and Constraints
• System Capabilities
• Level of Service Goals

10
Dependencies (Continued)

• SSRD depends on FRD
• Changes considered but not included
• SSRD depends on prototype for
• User/system interface requirements
• Nominal (feature) requirements
• Additional documents depend on SSRD
• SSAD to obtain (and consistency trace)
• System and Project Requirements
• FRD to check for satisfaction of
• All requirements

11
Requirements

• Defines the system concept (from OCD) with
  respect to general technology considerations
• Must, Shall, Will instructions for
  implementers
• An assurance contract for the customers
• Necessarily a high-level activity
• ties OCD to SSAD with respect to FRD
• allows planning within LCP
• provides an outlet from WinWin
• provides tangible criteria for project success
• Requirements can be tested/reviewed against
• not a good way to start a project
• Can be misunderstood or abused

12
Main Kinds of Requirements

• Project Requirements (SSRD 2)
• global to project, affects overall system
  requirements
• Capability Requirements (SSRD 3)
• local to system, specific system functionality
• System Interface Requirements (SSRD 4)
• varies, affects groups system requirements
• Level of Service Requirements (SSRD 5)
• local to system, may affect many system
  requirements
• Evolutionary Requirements (SSRD 6)
• varies, affects design and implementation

13
Necessary Condition

• All requirements must be testable and
  implementable (subject to risk considerations)
• There must be some way to demonstrate that a
  requirement has been satisfied by the system
  (will be documented in FRD)
• System Capability supports a typical or
  non-trivial scenario (Use-Case)
• Project must have a measure, what is being
  measured, definition of satisfactory
• Level of Service must have a measure, specific
  instances with respect to capabilities,
  satisfactory threshold (relative measures are
  useful)
• System Interface must specify checklist for all
  interface parameters
• Evolutionary must refer to a design or
  implementation scenario that supports a possible
  future satisfaction

14
SSRD 2 Project Requirements

• General assumptions and constraints placed upon
  the design team
• If not met, stakeholders would not be satisfied
  or would not accept system
• Describe non-negotiable global constraints e.g.,
  solution constraints on the way that the problem
  must be solved, such as a mandated technology
• Refine Project Goals (OCD 4.2)
• Should be M.A.R.S. (Measurable, achievable,
  relevant, specific)

15
SSRD 2 Project Requirements (cont.)

• Budget and Schedule
• Development and transition time
• Cost limits for development, transition and
  support
• Development Requirements
• As appropriate include
• Tools and Programming Languages
• Computer Resources
• Standards compliance
• Packaging Requirements
• Installation, post- installation, delivery

16
SSRD 2 Project Requirements (cont.)

• Implementation Requirements
• Personnel and staffing
• Training
• Development environment including hardware
• and software
• Support Environment Requirements
• Tools required
• Personnel and skills required

17
Example Vacation Sick Leave (VSL) SSRD

• SSRD 2.0 Project Requirements
•   Budget The system requires 8350 for
  transition cost, there is no hardware and
  software cost for this system. 400/month for
  maintenance cost and 1316/month for operational
  cost. (see LCP 2, 5 FRD 2.1)
• Schedule The system is to be completed within
  24 weeks. The first 12 weeks are used to complete
  system Life Cycle Objectives (LCO) and
  Architecture (LCA), which includes system
  operational concept (OCD), prototype, system
  requirements (SSRD), system and software
  architecture (SSAD), life-cycle plan (LCP),
  feasibility rationale (FRD) and WinWin
  negotiations. The second 12 weeks are used to
  implement and deliver the system. (refer to LCP
  2,3,4,5)

18
SSRD 3.
4.1)
19
SSRD 3.1 System Definition

• Diagram is old style
• Shows system boundary, internal components,
  interacting entities
• You should instead use a class diagram one or
  more object diagrams

20
3.1 Multimedia Scheduling System

• The software system takes in users requests via
  web-based interfaces and stores them in data
  storage for later review. Once staff members are
  notified, the requests are brought up for
  approval. Either rejection or approval would get
  the users notified via email.
• The Multimedia Scheduling System comprises two
  subsystems
• 1. The web-based request form used by users
• The users fill out an online form to request a
  reservation. The form is processed and the
  system sends a confirmation email to the users.
• 2. The web-based request approval forms used by
  administrators
• System administrators are in charge of viewing,
  approving and rejecting requests. Super Admins
  responsibility is a superset of system
  administrators that also includes setting up the
  system and creating passwords.
•          Password Authentication Administrators
  connect to the
• Admin Area and are prompted to
  enter passwords.
•          Request Approval Administrators
  approve the pending
• requests.

21
Can Include Context Diagram
It may be appropriate to copy (or reference) the
context diagram from the OCD.
Diagram shows system users, services to be
provided by the system
22
SSRD 3.2 System Requirements

• System requirements are a refinement of
  Capabilities (OCD 4.3)
• Define the nominal and the off- nominal cases
• Nominal cases typical system conditions
• Off- nominal cases exceptional and abnormal
• conditions, e.g., error conditions
• Indicate the required robustness.
• During LCO include the most important
  requirements
• Add more requirements during LCA

23
Example System Requirements VSL

• The subsystem would provide two levels of access
  employee (staff or faculty) and Supervisor. The
  system checks authentication and then displays
  different web pages and performs different
  functions for different roles.
• Each user inputs and submits his/her monthly
  Vacation/Sick Leave report
• User can query his/her vacation/sick leave
  history records
• The supervisor reviews the monthly Vacation/Sick
  Leave reports submitted by the employees in
  his/her department.
• Supervisor can request system to show a summary
  report which lists his/her employees usage and
  balance of leave information.
• When the user wants to input the date into
  Monthly Report, the calendar will pop-up to help
  user choose the date.
• Etc.

24
SSRD 3.2 System Requirements (cont.)

• System Requirements
• Prioritize the requirements based on the WinWin
  negotiations
• Every capability requirement should be testable
• Modes and user classes possible
• E. g. Operational mode vs. Training mode
• Administrators vs. Surfers
• Use structured Use- case diagrams with attached
  Activity diagrams where the actions and events
  exceed what can be explained in 3 sentences

25
Example of System Modes

• A multimedia archive system may operate in the
  following modes
• User mode when users access the archive
  (database opened in shared mode)
• Administrator mode when the administrator is
  modifying the archive (database opened in
  exclusive mode)
• Maintenance mode when the administrator is
  performing repair, backup or compacting
  operations (database is shutdown)

26
Content of a Requirement Specification

• Number
• Name
• Description
• Priority
• Rationale
• Constraints
• Dependencies
• Risks
• Traceability reference to WinWin artifact and
  System Responsibility (OCD)

• Inputs
• Actions
• Events
• Interactions
• Sources
• Outputs
• Stimuli
• Destinations
• Pre-conditions
• Post-conditions
• Side effects

Select appropriate elements from this list to
cover essential processing
27
Example of Nominal Requirement
28
(No Transcript)
29
SSRD 4. System Interface Requirements

• User Interface Requirements
• Describe required user interfaces if
  applicable GUI,
• command line, textual menu, diagnostics and
  logs
• Hardware Interface Requirements
• Describe interfaces to special hardware such as
• scanners
• Communications Interface Requirements
• Describe Interface with network if applicable
  (e.g., tcp/ip)
• Software Interfaces
• Describe APIs used and provided

30
SSRD 5. Level of Service Requirements

• Describe desired and required qualities of the
  system
• How well should the system perform
• An LOS requirement should normally add specifics
  to
• A Level of Service goal from OCD 4.4
• A System Requirement from SSRD 2
• These traces should be shown explicitly
• Provide MARS Criteria (Measurable, Achievable,
  Relevant, Specific)
• Specify the units of measurement.
• Provide desired and acceptable levels
• FRD should validate how the architecture can meet
  the level of service requirements

31
Example Levels Of Service

• Dependability
• Reliability (e.g., frequency of correct answer)
• Availability (e.g., of time system can be used)
• Usability
• Ease of learning
• Ease of use
• Performance
• Response time
• Maintainability
• Portability (list of required system hosts)
• Inter-operability (or binary portability)
• Reusability (e.g., of modules which can be used
  in a future specified system)

32
Example Level Of Service
33
Example Feasibility (for FRD)
Sample FRD achievability assessment (FRD
2.2.3.4)  2.2.3.4 QR-8 Response Time The support
of heterogeneous servers in IBM digital library
allows you to use the system for all kinds of
data, while optimizing the processing of
individual data types. This would in turn reduce
the response time for a search request. Also, the
support for multiple, distributed object servers
allows digital objects to be placed close to the
users who need to access these objects
frequently. This helps in delivering large
multimedia objects (like images) fast. The
specifications for V.2.3 of the IBM digital
library package indicates that the query rate is
average of 10,000 rows per second for a single
attribute query. The query is over a maximum of
four attributes (title, author name, descriptor,
and notes), so the query rate is no more than
four independent queries over these attributes
(or 10,000/4 2,500 rows per second) minus the
time to find intersections (for and searches)
which is O(n2). Thus in 10 seconds 25,000 rows
(the items) can be returned and compared for
intersections giving approximately 150 items.
The T1 transmission can deliver 1MB/s and each
item is less than 500 ASCII characters long, so
transmission is not an issue. Thus it is feasible
that QR-8 can be achieved.
34
Poor Examples
M The system should be as fast as possible
R The system should be available 24/ 7 (in a
situation where the organization does not support
activities beyond day time) S The system shall
be implemented as per the standards laid out by
USC A The system shall be available 100 of
the time (for an unreliable network- based
system)
35
SSRD 6. Evolution Requirements

• Description of required levels of flexibility and
• expandability
• Description of the foreseeable directions of the
  system growth and change
• Description of how the software and data assets
  will be maintained
• Facilities
• Equipment
• Service-provider relations
• Maintenance levels
• Maintenance cycles
• etc...

36
SSRD 6.1 Capability Evolution

• Major post-IOC capability requirements
• Capabilities considered but deferred
• May be used to risk manage system requirements
  with respect to project and level of service
  requirements
• More than a feel good place holder - must be
  accounted for within architecture must also be
  testable.

37
Examples of Capability Evolution
1. Data input using Voice Recognition One
proposed feature that has not been kept in the
system design is one of voice recognition. In
future, when voice recognition is available the
system should allow the operator to simply speak
the data that has to be entered and the database
should be accordingly modified. For this an
interface has to be provided. 2. Different levels
of access to the archive (subscription) In
future, different levels of access to the archive
items could be provided to the user. This would
allow a set of users to have a wider access to
items that could not have been archived
otherwise. Also, the Boeckmann Center would get
funds for its maintenance. 3. Full Browse
Capability This would have been an enormous
additional task. The implementation of this could
be a project on its own. It was not a requirement
of the customer so it was not even considered in
the WinWin negotiations.
38
SSRD 6.2 Interface Evolution

• How must the system adapt to interface changes in
  the future?
• Organizational changes in use of system
• Personnel changes (more, less, different style)
• New or expanded product lines
• Policy changes
• Organization restructure
• New/additional/dissolved relationships
• External systems
• New/additional/replacement systems
• Changes in external interfaces

39
SSRD 6.3 Technology Evolution Reqs

• Describe how system adapts to future releases of
  external and COTS software
• Future technology change adaptation
• SSRD 6.4 Environment and Workload Evolution
• Change in workload
• Change in organizations supported COTS products

40
SSRD 7. Common Definition Language for
Requirements

• Definitions of unfamiliar terms, and acronyms
  encountered or introduced during the requirements
  elicitation process
• Do not repeat the common definition language from
  OCD 6 (will make it harder to ensure consistency)
• SSRD should be understood by everyone in the
  target audience
• Example
• Context-related help This help describes the
  help for a given context. For example, this kind
  of help would describe a screen, its contents,
  and its use.