SUPPLEMENTARY SPECIFICATION DOCUMENTDefinition:

The Supplementary Specifications capture the system requirements that are not captured in the use cases or other documents. Such requirements include:

• Legal and regulatory requirements and application standards. • Quality attributes of the system to be built, including usability, reliability,

performance and supportability requirements. • Other requirements such as operating systems and environments, compatibility

requirements, and design constraints.

Usability Usability should include all of those requirements that affect usability. Examples:

• Specify the required training time for a normal users and power users to become productive at particular operations.

• Specify measurable task times for typical tasks or base usability requirements of the new system on other systems that the users know and like.

• Specify requirements to conform to common usability standards – e.g., GUI standards published by Microsoft for Windows XP.

Reliability Requirements for reliability of the system should be specified here. Suggestions:

• Availability – specify % of time available (xx. xx%), hours of use, maintenance access, degraded mode operations etc.

• Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output.

• Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs per function-point.

• Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a “critical” bug (e.g., complete loss of data, complete inability to use certain parts of the functionality of the system).

Performance The performance characteristics of the system should be outlined in this section.

Include specific response times. Where applicable, reference related Use Cases by name. • Response time for a transaction (average, maximum) • Throughput (e.g., transactions per second) • Capacity (e.g., the number of customers or transactions the system can

accommodate) • Degradation modes (what is the acceptable mode of operation when the system has

been degraded in some manner) • Resource utilization: memory, disk, communications, etc.

Supportability

This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.

Design Constraints This section should indicate any design constraints on the system being built.

Design constraints represent design decisions that have been mandated and must be adhered to. Example: software languages, software process requirements, prescribed use of

developmental tools, architectural and design constraints, purchased components, class libraries, etc.

Online User Documentation and Help System Requirements It describes the requirements, if any, for on-line user documentation, help

systems, help about notices, etc.

Purchased Components It describes any purchased components to be used with the system , any applicable

licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.

Interfaces This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc, so that the software can be developed and verified against the interface requirements.

i)User Interfaces Describe the user interfaces that are to be implemented by the software.

ii) Hardware Interfaces This section defines any hardware interfaces that are to be supported by the

software, including logical structure, physical addresses, expected behavior, etc.

iii) Software Interfaces This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact.

iv) Communication Interfaces Describe any communications interfaces to other systems or devices such as local

area networks, remote serial devices, etc.

Licensing Requirements Define any licensing enforcement requirements or other usage restriction

requirements that are to be exhibited by the software.

Legal, Copyright and Other Notices

Other Requirements Each transaction must include the following information:

• The terminal ID.

• The unit ID • The Date and Time • The User ID • Credit card number • Authentication code (from credit card company) • List of media played and the unit price.

Applicable Standards [This section describes by reference any applicable standards, such as in-house coding standards, data standards, etc.

Supplementary Specification: 

Supplementary Specification Requirements are categorized by FURPS+ F = Functional Requirements Use Cases address the F requirements Supplementary Specification contains the URPS+ requirements Usability Reliability Performance Supportability + others?

Supplementary Specification Use Cases Strengths Detailing interaction with external actors Documenting business processes Weaknesses Highly algorithmic or computational systems Solutions Capture math formulas in Business Rules Formulas Calculations Lists of data Activity diagrams Embedded systems State machine models

Supplementary Specification Usability Is always an issue Difficult to measure Vary from customer to customer How should we document/measure?

Supplementary Specification Measurement Approaches Training time User productivity metrics Task metrics Benchmarking Published/Tested results of other systems Increase Usability Customization and Visual cues Tooltips Assistance/First time tutorials Help manuals Training scenarios

Supplementary Specification User’s Bill of Rights (Karat 1998) User is always right Easily install/uninstall SW System must perform as promised Easy-to-use documentation User right to be in control of the system User always informed about task status & progress User clearly informed about all requirements to use system User knows system’s limits and capabilities User receives helpful prompts System is natural and intuitive to use

Supplementary Specification Reliability How to measure Availability Must be up 99.999% of the time 24/365 Mean Time Between Failures (MTBF) What are considered failures? Mean Time To Repair (MTTR) 90% of failures repaired within 15 minutes Vendor response In person on site By telephone

Supplementary Specification More Reliability measures Accuracy Outputs must be reliable Low defect rate Measured in Defects per X Lines of Code Defect severity Minor Important Major

Supplementary Specification Performance Response times for transactions Throughput Capacity Max user load How many users before system degradation Maintain 80% throughput when 120% of capacity Failover are always a good idea If node goes down, system @ capacity within 5 minutes

Supplementary Specification Supportability Clients have to be knowledgeable or know where to find info Developers should be trained on system maintenance Architectural integrity Follow OO architecture Design patterns (Covered in 2511) Documentation of

system architecture Use UML to model system Ongoing support Provide customer support at least during hours of possible use Update system documentation with each release

Supplementary Specification Constraints on Design Hardware and/or Software restrictions RDBMS OS Server SW design process Regulatory Local State Federal laws

Supplementary Specification Document any additional relevant information artifact (that need created) Decision Rational List of features/reasons things weren’t done Anything else the requirements might have missed Training

USE CASE SPECIFICATION DOCUMENT:

Use case:• A use case is an abstraction of a required behavior of a system. • A use case produces an observable result of value to the user. • A typical system will have many use cases each of which satisfies a goal of a particular

user. • Each use case describes a sequence of interactions between one or more actors and the

system. • A use case narrative is written in a natural language. It is written as a sequence of

numbered steps with a main success scenario and alternate flows. • This sequence of interactions is contained in a use case report and the relationships

between the system and its actors are portrayed in use case diagrams.

Use case-Purposes:Use cases are used for the following purposes:

To reach a common understanding of system behavior To design elements that support the required behavior

To identify test cases

To plan and assess work

To write user documentation.

Use case-outline:A use case typically includes the following information:

Name: The name of the use case Brief Description: A brief description of the role and purpose of the use case

Flow of Events: A textual description of what the system does in regard to a use case scenario (not how specific problems are solved by the system). Write the description so that the customer can understand it. The flows can include a basic flow, alternative flows, and subflows.

Key scenarios: A textual description of the most important or frequently discussed scenarios

Special Requirements: A textual description that collects all of the requirements of the use case that are not considered in the use-case model, but that must be taken care of during design or implementation (for example, non-functional requirements)

Preconditions: A textual description that defines a constraint on the system when the use case starts

Post-conditions: A textual description that defines a constraint on the system when the use case ends

Extension points: A list of locations within the flow of events of the use case at which additional behavior can be inserted by using the extend-relationship

Use case- strengths:

• Simple concept• Easy to comprehend and follow-Contingent on writing skill• User focused – ensures that you consider how the system supports its environment• Easy to review with non-technical stakeholders• Easy to incorporate soft topics like goals, capabilities and expectations.

Use case- weaknesses:• Lack precision-Use cases feel vague• Relatively hard to document and organize lots of necessary details• Use cases are not yet used by everyone• Hard to definitively “sign off” a use case for acceptance testing

Requirements and use cases:• Specific Requirements• Functional requirements state, in formal shall statement notation, the functions that the

system must execute.• Nonfunctional requirements are often performance requirements that specify how well

the system must execute certain functions.• Supplementary Requirements Specification contains the requirements that are associated

with more than one use case. Often they are system wide. Examples include cost, schedule, reliability, availability, technology, design life,etc.,

Use case-concept:A use case describes the interactions between one of more Actors and the system in order to provide an observable result of value for the initiating actor.

The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain the observable result of value) for a particular actor.

In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the system. 

ATM Use-Case Example

Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible ways of using the system. You should be able to determine the goal of a use case simply by observing its name.

A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s) and the system, structured as follows:

1. The actor <<does something>> 2. The system <<does something in response>>

3. The actor <<does something else>>

4. The system ...

Each dialog of this form is called a "Flow of Events".

Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required network connection is currently unavailable), each use case will contain several flows, including one "Basic Flow of Events" and several "Alternative Flows".

The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the main capability provided by the system for this use case.

As the name implies, Alternative Flows specify alternative interactions associated with the same goal.

Closely related to use cases is the concept of a scenario. A scenario is a specific flow of events, for a specific set of inputs to the system, states of the system, and states of the system's environment. Scenarios are closely related to test cases.

Properties of Use Cases

Name

Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have to be several words to be understood. Note: No two use cases can have the same name.

Brief Description

The brief description of the use case should reflect its purpose.

Flow of Events

Flow of Events - Contents

The flow of events should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow of events should represent what the system does, not how the system is design to perform the required behavior.

Follow these guidelines for the contents of the flow of events:

Describe how the use case starts and ends. Describe what data is exchanged between the actor and the use case.

Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system. Specifying user interface details too early will limit design options. 

Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... ".

Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system.

Avoid vague terminology.

Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify test cases.

Flow of Events - Structure

The two main parts of the flow of events are basic flow of events and alternative flows of events. The basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of which will return to the basic flow of events and some of which will end the execution of the use case.

Both the basic and alternative flows should be further structured into steps or sub-flows. In doing this, your main goal should be readability of the text. A guideline is that a sub-flow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the sense that you do either all or none of the actions described.

Special Requirements:

In the Special Requirements of a use case, you describe all the requirements associated with the use case that are not covered by the flow of events. These are non-functional requirements that will influence the design.

Preconditions and Post-conditions:

A precondition is the state of the system and its environment that is required before the use case can be started. Post-Conditions are the states the system can be in after the use case has ended. It can be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts and ends. However, only use them only if the audience for the description of the use case agrees that it is helpful. Figure 3 shows an example.

Illustration of preconditions and resulting post-conditions

Examples:

A precondition for the use case Cash Withdrawal in the ATM machine: The customer has a personally issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.

A post-condition for the use case Cash Withdrawal in the ATM machine: At the end of the use case, all account and transaction logs are balanced, communication with the banking system is reinitialized and the card is returned to the customer.

METHODS FOR SOFTWARE PROTOTYPING:

Software Prototyping Process: Software prototyping is the process of creating an incomplete model of the future full-

featured software

A prototype can be used to give end-users a concrete impression of the system’s capabilities

Prototyping is becoming increasingly used where rapid development is essential

IEEE defines prototyping as “A type of development in which emphasis is placed on developing prototypes early in the development process to permit early feedback and analysis in support of the development process.”

Process:

• Identify basic requirements

• Develop Initial prototype

• Review with customers users

• Revise and enhance

Prototyping Process:

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Types of Software Prototypes:

Throwaway prototype: process of creating a rapid model (demonstration or marketing)

Evolutionary prototype: build a system then refine Incremental: final product built as separate prototypes

Applications: Feasibility (must use) Human Interface testing Increases user involvement Reduce time and cost DSDM (Dynamic Systems Development Method)

Business prototypes (automation/mechanization)

Usability prototypes

Performance and Capacity

Proof of concept

Prototypes:

Plan to build a prototype Document feedback from customer for the prototype. Manage the feedback into the software product

Prototyping with Reuse:

1) Application level development

• Entire application systems are integrated with the prototype so that their functionality can be shared

• For example, if text preparation is required, a standard word processor can be used

2) Component level development

• Components are mutually independent

• Individual components are integrated within a standard framework to implement the system

• Framework can be a scripting language or an integration platform.

Reusable component composition:

Componentcompositionframework

Executableprototype

Reusablesoftware

components

Control andintegration code

Prototyping Benefits:

Misunderstandings between software users and developers are exposed

Missing services may be detected and confusing services may be identified

A working system is available early in the process

The prototype may serve as a basis for deriving a system specification

The system can support user training and system testing

Improved system usability

Closer match to the system needed

Improved design quality

Improved maintainability

Reduced overall development effort

Prototyping Approaches:

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements

Prototyping as methodology for systems development:

A preliminary design of the system is built using throw-away prototyping.

Demonstrations to end users, as well as investigations on this prototype, allows for the design of more precise requirements as well as the evaluation of techniques to be used in the final system.

Refinements on throw-away prototype concerning the requirements are done.

Evolutionary prototyping used to build a model prototype (an accurate and complete description of the system). These prototypes can be studied under various simulated conditions.

Refinement on model prototype, concerning the actual system, is done and final system is rolled out after testing.

Prototyping Objectives:

The objective of evolutionary prototyping is to deliver a working system to end-users

• The development starts with those requirements which are best understood.

The objective of throw-away prototyping is to validate or derive the system requirements

• The prototyping process starts with those requirements which are poorly understood

Needs for Prototyping:

Enables us to explore the problem space with the stakeholders.

As a requirements artifact to initially envision the system.

As a design artifact that enables us to explore the solution space of your system.

A vehicle for you to communicate the possible UI design(s) of your system.

A potential foundation from which to continue developing the system

Key points:

Throw-away prototyping is used to understand the system requirements

In evolutionary prototyping, the system is developed by evolving an initial version to the final version

EVOLUTIONARY PROTOTYPING:

Must be used for systems where the requirements specification cannot be developed in advance

Based on techniques which allow rapid system iterations

Verification is impossible as there is no specification.

Validation means demonstrating the adequacy of the system

Evolutionary Prototyping Flow:

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Evolutionary Prototyping Technologies:

• Specification, design and implementation are inter-twined

• The system is developed as a series of increments that are delivered to the customer

• Techniques for rapid system development are used such as CASE tools and 4GLs

• User interfaces are usually developed using a GUI development toolkit

Evolutionary Prototyping Challenges

1) Management problems

• Existing management processes assume a waterfall model of development

• Specialist skills are required which may not be available in all development teams

2) Maintenance problems

• Continual change tends to corrupt system structure so long-term maintenance is expensive

3) Contractual problems

Advantages of evolutionary prototyping:

Accelerated delivery of the system

• Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability

User engagement with the system

• Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

You are always looking for new ways to improve the system.

This model increases the chance of having the client satisfied with the working system.

The model can be used even when the requirements are not defined.

Quicker delivery of the system

Disadvantages of evolutionary prototyping:

This method can be used to avoid documenting the requirements of the system.

Management is required

Long term maintenance can be expensive

Uncertain design idea’s

Information can be lost through so many improvement changes

Prototypes as Specifications:

Some parts of the requirements may be impossible to prototype

• E.g., safety-critical functions

An implementation has no legal standing as a contract

Non-functional requirements cannot be adequately tested in a system prototype

Incremental Development:

System is developed and delivered in increments after establishing an overall architecture

Requirements and specifications for each increment may be developed

Users may experiment with delivered increments while others are being developed

• These serve as a form of prototype system

• Intended to combine some of the advantages of prototyping

• More manageable process

• Better system structure

Evolutionary prototyping Phases:

Incremental Development Flow:

THROW-AWAY PROTOTYPING:

Used to reduce requirements risk

The prototype is developed from an initial specification, delivered for experiment then discarded

The throw-away prototype must NOT be considered as a final system

Some system characteristics may have been left out

There is no specification for long-term maintenance

The system will be poorly structured and difficult to maintain

Throw Away Prototype is developed from the initial requirements but is not used for the final project.

Written specifications of the requirements

Some developers believe that this type is a waste of time because you don’t use it.

Regardless if prototype is discarded or kept for production, you must use a easy to use language.

Prototype delivery:

Developers may be pressurised to deliver a throw-away prototype as a final system

This is not recommended

• It may be impossible to tune the prototype to meet non-functional requirements

• The prototype is inevitably undocumented

• The system structure will be degraded through changes made during development

• Normal organisational quality standards may not have been applied.

Advantages of throwaway prototyping:

Significantly reduce project risk

Has a short project timeline

Disadvantages of throwaway prototyping:

The prototype actually does nothing, its just presentational.

Only for a limited purpose

Starting became a thing of the past. Not getting used as much now.

RAPID PROTOTYPING TECHNIQUES:

Various techniques may be used for rapid development are as follows;

1. Dynamic high-level language development

2. Database programming

3. Component and application assembly

These techniques are often used together

Visual programming is an inherent part of most prototype development system

1.Dynamic High-level Languages:

Languages which include powerful data management facilities

Need a large run-time support system. Not normally used for large system development

Some languages offer excellent UI development facilities

Some languages have an integrated support environment whose facilities may be used in the prototype

2. Database Programming Languages:

Domain specific languages for business systems based around a database management system

Normally include a database query language, a screen generator, a report generator and a spreadsheet.

May be integrated with a CASE toolset

The language + environment is sometimes known as a fourth-generation language (4GL)

Cost-effective for small to medium sized business system

DBprogramming

language

Interfacegenerator Spreadsheet

Reportgenerator

Database management system

Fourth-generation language

3. Component and application assembly:

Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together

The composition mechanism must include control facilities and a mechanism for component communication

The system specification must take into account the availability and functionality of existing components

Compound documents:

For some applications, a prototype can be created by developing a compound document

This is a document with active elements (such as a spreadsheet) that allow user computations

Each active element has an associated application which is invoked when that element is selected

The document itself is the integrator for the different applications

Visual programming:

Scripting languages such as Visual Basic support visual programming

the prototype is developed by creating a user interface from standard items and associating components with these items

A large library of components exists to support this type of development

These may be tailored to suit the specific application requirements

Visual programming with reuse:

File Edit Views Layout Options Help

GeneralIndex

Hypertextdisplay componentDate component

Range checkingscript

Tree displaycomponent

12th January 2000

3.876

Draw canvascomponent

User promptcomponent +

script

Problems with visual development:

Difficult to coordinate team-based development

No explicit system architecture

Complex dependencies between parts of the program can cause maintainability problems

User interface prototyping:

It is impossible to pre-specify the look and feel of a user interface in an effective way

UI development consumes an increasing part of overall system development costs

User interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entities

Web interfaces may be prototyped using a web site editor

Mindset:

Prototyping is critical system parts that cannot be effectively pre-specified

Rapid prototyping focus on partial functionality

Prototyping techniques include the use of tools, very high-level languages and database programming

Users must be involved in prototype evaluation

Growing from Prototype to Model: