Chapter 22:         Developing the Supplemental Specification

 

A.  Nonfunctional requirements are the most important part of the supplemental spec:

 

1.  These are  “Attributes of the system” or its environment and must be managed well, just like functional requirements (features, etc.)

 

2.  As a requirements manager --

Your goal on both

  functional and

  nonfunctional requirements

is to capture requirements in a way which shows how the system must

  function or

  operate,

a way that leads to

  progressive elaboration during development & testing

and so satisfies customer requirements.

 

With functional requirements, we employ use cases for this.

With nonfunctional requirements, we employ scenarios for this.

 

3.  What are some of these nonfunctional requirements?

 

·           Leffingwell & Widrig’s “Nonfunctional” (quality) requirements to consider include these:

o          Usability

o          Reliability

o          Performance

o          Supportability

 

4.   How to capture these nonfunctional requirements in Scenarios (from Bass, et al, p. 75), in “a way that leads to progressive elaboration during development & testing and so satisfies customer requirements” :

 

Source of stimulus:  This is some entity (a human, a computer system, or any other actuator) that generated the stimulus.

 

Stimulus:  The stimulus is a condition that needs to be considered when it arrives at a system.

 

Environment:  The stimulus occurs within certain conditions.  The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.

 

Artifact:  Some artifact is stimulated.   This may be the whole system or some pieces of it.

 

Response:  The response is the activity undertaken after the arrival of the stimulus.

 

Response measure:   When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

 

à We’re going to use Bass et al’s list of principal nonfunctional requirements (Availability, Modifiability, Performance, Security, Testability, Usability) in our Template, which otherwise is like that shown in Ch 22, because Bass has specific details of these Scenarios associated with his principal nonfunctional requirements.

 

5.  What are these nonfunctional requirements, anyway? – a closer look (quote from Bass et al, pp. 79+):

 

Availability – Concerned with system failure and its associated consequences.  A system failure occurs when the system no longer delivers a service consistent with its specification.  Availability is the probability that it will be operational when it is needed.  This is defined as

 

                                           mean time to failure

a   =    -------------------------------------------------------

                        mean time to failure + mean time to repair

 

Reliability and Serviceability are related measures, and you should know how these relate to Availability.  Reliability, for example, is the probability the system will operate correctly in a specified environment up till time t.  So, say, if the system needs to operate for 10 hours at a time, that’s the reliability target.  All these terms are often described as a part of Dependability – See for example, http://www.cs.virginia.edu/~jck/cs651/slides/terminology.pdf .

 

Modifiability – This is about the cost of change.  The two concerns are (1) What can change (the artifact)? And (2) When is that change made and who makes it (the environment)?

 

Performance – Performance is about timing.  Events (interrupts, messages, requests from users, or the passage of time) occur, and the system must respond to them.  Capacity is a related issue.  Basically, performance is concerned with how long it takes the system to respond when an event occurs.  Typically performance requirements focus-in on the peak load that a system must handle, and try to characterize the priorities and relative responsiveness expected during that most stressed period of time.

 

The calculation of system capacity requires that one describe the operational profile for that system – what does it have to do under different modes of operation?  Especially, what does is normal operating load look like during the day, and what off-hours maintenance activity must it handle?

 

Security – This is a measure of the system’s ability to resist unauthorized usage while still providing its services to legitimate users.  An attempt to breach security is called an attack (or threat) and can take a number of forms, such as an attempt to access data or services or to modify data, or an attempt to deny service to legitimate users.

 

Testability – This refers to the ease with which software can be made to demonstrate its faults through (typically) execution based testing.  At least 40% of the cost of developing well-engineered systems is taken up by testing.  In particular, testability refers to the probability, assuming that the software has at least one fault that it will fail on its next test execution.

 

Usability – This is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides.  It can be broken down into (1) Learning system features, (2) Using the system efficiently, (3) Minimizing the impact of errors, (4) Adapting the system to user needs, and (5) Increasing confidence and satisfaction.  We’ll talk more about usability later in this class.  Lots of good references to this subject out there on the web, etc.  E.g., the Yale Web Style Guide, as tips for gathering requirements for web-based interfaces – See http://www.webstyleguide.com/ .

 

 

B.  What else goes into the Supplementary Spec?

 

·      Design Constraints --

o          Restriction of Design Options (e.g. what database to use)

o          Process (e.g. must use ISO or IEEE software engineering standards)

o          Regulations (e.g. FDA)

 

o          Why are these in the requirements, if they involve design?  Because it is part of what the customer wants or needs in the system to be developed.

 

·           “Other” Requirements (Leffingwell’s categorization) --

o          Deliverables (e.g. user documentation, other artifacts to be supplied by the developer – may in part depend on who’s doing the maintenance

o          Technical Support

o          Training Requirements

o          Some organizations will include these in the “nonfunctional requirements” (as in Bass, et al, above)

 

·           Don’t get bogged down on, say, whether something is a nonfunctional requirement or a design constraint – just make your best guess and include it!

 

C.  How to do the Supplementary Spec for your project:

 

·           Supplemental Specification template:

     http://www.rose-hulman.edu/class/csse/csse371/Handouts/SupplementarySpecTemplate.htm (includes description of nonfunctional scenarios, and adjusted to show Bass et al’s list of nonfunctional requirements)

 

·           Supplemental Specification examples (not necessarily in same format as template and don’t show nonfunctional scenarios):

     http://www.rose-hulman.edu/class/csse/csse371/Handouts/SupplementarySpecExamples.htm

 

·        We also will use the Scenario Format described in A 4, above, for non-functional requirements.

 

D.  In class – Let’s try doing one of these together, say, for security.  (Ref the Template document.)

 

E.  Exercise – In your new teams, use the Supplementary Spec template to write two (new) scenarios for performance based on what you know of the term project.  Then do one for availability.

 

 


[1] Software Architecture in Practice, Second Edition, by Len Bass, Paul Clements and Rick Kazman.  Addison-Wesley, 2003, ISBN 0-321-15495-9, pp. 71+.