Process Definition Document

for

MSE 530

Software Requirements Engineering

Table of Contents

1. Introduction

1. Purpose

The purpose of this document is to define a process to develop a software requirement specification document that is correct, unambiguous, complete, consistent, prioritized, verifiable, modifiable and traceable. The process will be general in nature to allow for the development of an object-oriented specification, as well as, a structured specification.

The intended audience for this document is anyone participating in the MSE 530 class (Software Requirements Engineering) at Embry-Riddle Aeronautical University in Daytona Beach, FL during the spring 2000 semester. Specifically, this document and its process will be used by Jason Carrow, Chris Marchant and Pat Mukdaprakorn to develop software requirement specifications in the future.

2. Scope

The defined process will capture the following properties of the software requirement specification process:

• Requirement Elicitation

• Requirement Analysis

• Requirement Specification

• Traceability and Change Management

• Requirement Engineering Measurement

The defined process will be beneficial to its audience by providing a framework for the development of software requirement specifications in the future. It will provide sequential scripts, when executed correctly, which will yield a final software requirement specification that is correct.

The scope of this document assumes that the audience has knowledge of software engineering. It will not provide a detailed description, or a script, for tasks that are considered routine for beginning software engineers.

3. Definition, acronyms, and abbreviation

The table below defines definitions, acronyms, and abbreviations that will be used throughout this document.

Acronyms

SRS Software Requirement Specification

TRL Time Recording Log

PIP Process Improvement Plan

RTM Requirements Traceability Matrix

RTT Requirements Traceability Table

REC Requirements Elicitation Checklist

RAC Requirements Analysis Checklist

RVC Requirements Verification Checklist

RTMC Requirements Trace Checklist

A system stakeholder is anyone who benefits in a direct or indirect way from the system, which is being developed.

Source of requirements is a link to the information on which the requirement is based. A requirement source can be any stakeholder, organizational standard, technical documentation, incident reports, or other requirement documents.

A Context-diagram is a diagram consisting of one circle (or eclipse), which represents the system, that is typically placed in the center of the diagram; rectangles are used to represent entities, hardware and software, that are external, yet required interfaces, to the system to be developed; and finally, a pair of double lines represents any data storage that is required or produced.

Business Concerns are abstract high-level goals that must be satisfied if a system is to make contribution to organization, which is paying for it.

The rationale of requirement is the information which summaries the reasons why that requirement has been specified. The rationale is derived from a source.

Requirements Traceability Matrix (RTM) is a matrix that initially contains the set of requirements for the system. The RTM is continually enhanced throughout the process of requirement engineering and the lifetime of the project.

Application Domain Knowledge: is knowledge of general ideas where the system is applied.

Checklist is the set of questions that the analyst uses to assess each requirement.

Performance Requirement is the statement that specifies either timing or sizing restriction on either a hardware device or a functional subset of the software.

Software Constraints is a restriction potentially placed on the software implementation.

Build is specification of software functionality to be developed by a specific date. A build is a part of a release, used for internal management purposes to track the development of a release to a customer.

Release is a distribution of software functionality to the customer. A release is made up of one or more builds. A release has a specific version number associated with it, to help identify the specific set of functionality included in the delivered software.

Action represents a capability requested of the software. An Action is the specific subset of functionality that can be requested by an Actor. An Action is a statement of requested processing.

Actor represents a stimulus to the software system. The stimulus can be external to the software system, or internal created by the software itself. An Actor requests a specific set of control.

Qualifier is a mechanism for refining a Use Case Actor or Subject, and thus aids in the discovery of inheritance hierarchies.

Role represents the set of responsibilities for an Actor of software system. An Actor may play several roles.

Subject represents the item acted upon by an Action requested of the software. A subject is a domain entity that has a responsibility of fulfilling the request for the functionality of a specific Use Case.

Use Case is a statement of functionality required of software. A Use Case is written in the specific format. The specific format of Use Case is

Actor Action Subject

4. Reference

The following references were used in developing this document and the process contained within:

Humphrey, W. S., (1995). A discipline for software engineering. New York, NY: Addison-Wesley.

Marchant, C., et. al. (1999). Software design process for MSE 610. Team 2, Version 1.1. Embry-Riddle Aeronautical University. Daytona Beach, FL.

Kotonya, G., Sommerville, I., (1998). Requirements Engineering: Process and techniques. New York, NY: John Wiley & Sons.

Sommerville, I., & Sawyer, P., (1997). Requirements Engineering: A good practice guide. New York, NY: John Wiley & Sons.

The Institute of Electrical and Electronics Engineers, (1994). IEEE recommended practice for software requirements specifications.

Gutcher, F., (January 2000). Presentation: Domain Analysis. Embry-Riddle Aeronautical University. Daytona Beach, FL.

Gutcher, F., (January 2000). Presentation: Software requirement specification standard. Embry-Riddle Aeronautical University. Daytona Beach, FL.

Gutcher, F., (January 2000). Handout: MSE 530: Software requirements engineering, (Assignment one handout). Embry-Riddle Aeronautical University. Daytona Beach, FL.

5. Overview

The remainder of this document contains the processes of requirements engineering. This includes Requirements Elicitation, Requirements Analysis, Requirements Validation, Requirements Specification, and Requirement Verification.

Each process phase contains the Process Description, the Process Guideline, and the Process Script. The requirement engineering can follow the direction in the Process Script and look for more detail in the Process Description and Process Guideline, which introduces the activities associated with each process phase.

2. Requirement Elicitation

   1. Process Description

Software requirement elicitation is the process where the customers' needs in a software project are identified. The use of methods and techniques to uncover, discover and communicate functional non-functional requirements and constraints.

To elicit system requirements, the analysts must understand the problem to be solved, the business processes in the organization, the way in which system likely to be used, and the application domain of the system. The analysts need to find out about the system from available documents and discuss with stakeholders the system services that they need and operational constraints on the system.

The following section lists the process guideline for this requirement engineering activity.

2. Process Guideline

   1. Requirement Review

The purpose of requirement review is to determine whether they are:

• Incomplete and / or missing,

• Feasible and appropriate to implement in the software,

• Clearly and properly stated,

• Consistent with each other,

• Testable, and

• Potentially create problems.

Process Step

The process conducted in this requirement review is based on the forms used as the review checklists. This activity will be conducted at various stage of the process: requirement

2. Identify the External Interfaces

The purposes of this activity are to identify and document the set of external interfaces for the system (hardware, software, and data store), and represent them using the context-diagram. The benefit of producing the context-diagram in this stage is to help visualizing the clear identification and definition of the external interfaces that interact which the system being developed. This will aid the requirement engineers in deriving the system constraints in the later phase of the process (See Appendix for the context-diagram example).

Process Steps

• Examine the existing documents: look for the operators, hardware devices, software systems, and persisting data.

• Produce the context-diagram: use the case tool if available

• Review with the domain expert: to ensure its correctness and to facilitate discussion that may lead to the significant leaps in knowledge

Output

• The context-diagram representing the external interfaces

3. Identify the System Stakeholders

The purpose of this activity is to discover all likely sources of requirements. A system stakeholder is anyone who benefits from the system, for example, the end-users, managers, customers, developers, and so on. This activity will prevent requirement engineers from missing important requirements.

Process Steps

• Use the following to identify the system stakeholders:

• By discovering the potential end-users of the system

• By considering the business process of the system, and people involved in this processes

• By initial discussion with the organization management about who will be affected by the introduction of the system

• By considering customers of the organization who will be using the system

• By considering the engineers and/or developers who will develop and maintain system

• By considering external bodies such as regulators and certification authorities who may which to place requirement to the system

• Produce the Stakeholders Table with their roles and a brief reason why their requirement is important

Output

• Stakeholders table (See Appendix)

Note: This stakeholder table can be used as a part of User Characteristics section in SRS.

4. Extract “shall” requirements

The purpose of this activity is to produce Requirement Trace Matrix (RTM) that contains the set of requirements from the original documents, consolidated documents from the interviewing section, or any other agree-upon documents.

Process Steps

• Agree to the initial set of documents

• Extract the shall statements

• Start filling RTM with the shall statements

Output

• The initial RTM: each row represent a single “shall” requirement

Note: If 2 sentences appear to mean the same thing, do not analyze at this time, simply at both sentences to the RTM.

5. Analyze Application Domain

The purpose of this activity is to identify the domain knowledge, which often lead to critical system requirements and/or constraints.

Process Steps

• Consult with the domain experts to find out what problems are likely to happen and what must be taken into account

• Record the domain information such as parameters, formulas used in calculation part of the system, terminology

Outputs

• Domain Dictionary: can be used in the terms and definition section of the SRS

• RTM with domain constraints and/or requirements

6. Define Operational Processes

A computer-based system is developed often to support some business processes. This activity reveals process requirements for the system and constraints, which will affected how the system may be used.

Process Steps

• Identify the actors and roles involved in the processes

• Identify activities for the processes

• Develop a simple diagrams and explanatory text representing these processes

Output

• Diagrams representing the business processes

3. Process Script

2. Requirement Analysis

   1. Process Description

The use of various methods to model software requirement in the information, function, and behavior domain of the problem. The engineer analyzes requirements for conflicts, overlaps, omissions, and inconsistencies. When the information from this analysis is available, system stakeholders then negotiate to agree on the set of requirements. Conflicts must be resolved and the requirement must be prioritized. Use the following process script and process guideline aid engineers achieving these goals.

2. Process Guideline

   1. Use Checklist for Requirement Analysis

The purpose of this activity is to systematically check each requirement and speed up the process of analysis. This technique of analysis reduces the accidental omission of some requirements. It is also a way of reusing the knowledge of the requirement analysis across projects.

Process Steps

• Answer the questions specified in the checklist (see Appendix) as reading through the RTM

• Annotate the potential problems

Outputs

• The checklist with answers

Note: The goal of analysis is to discover the potential problem; it is not a quality management activity.

2. Allocate Requirements

Without a stable set of requirements that are allocated to respective organizations for development, how can a system be developed? It is to define clearly the categories of requirements. This will help find the missing requirements. If the analyst find no requirement related to a common category of requirement scheme, this may mean that the important requirements were left out. It also improves the traceability of the requirement document. When requirement is made to some categories of requirements, the analyst may reconsider the requirements in the same categories.

Process Steps

• Categorize the RTM categories

  • DR => Derived Requirement

  • HW => Hardware Requirement

  • NTW=> Nice to Have (features)

  • P => Performance Requirement

  • SW => Software Requirement

  • SWC => Software Constraint Requirement

  • D(#nn) => Duplicate of RTM entry #nn

• Add categorize column to RTM

• Allocate category to each requirement

Output

• RTM with the category column

3. Prioritize Requirements

The purpose of prioritizing requirements is to allocate the Use Cases to a reasonable development schedule.

Process Steps

• Establish Definition of Build and Release (based this on the organization standard)

• Identify release: partition the software functionality into multiple releases

• Identify Builds/Releases

• Add the Build and Release columns to the RTM

• Complete each requirement with associated build and release number

Output

• RTM with Build and Release column

4. Identify Software Use Cases

The purpose of this activity is to extract the software requirements from the RTM and reformat these requirements to aid in the discovery of potential Categories. It is the transitions from the requirements to Use Cases.

Process Steps

• Establish the naming convention for the Use Case

• Agree upon Allowable Use Case Stimuli: constraining Actors to just Operator is quite inflexible with respect to requirement definition.

• Agree on the Quantity of Use Cases: too many Use Cases make for very detailed requirements and very thorough requirement trace

• Determine Strategy for Use Cases on Inheritance Hierarchies (See more detail in Texel and Williams, 1997)

• Extract Software Requirements as Use Cases: Examine each entry in the RTM that has a categorization of SW, restate a Use Case, specifically as Actor – Action – Subject

Outputs

• The updated RTM with the completion of the “Use Case,” “Class,” and “Method” column

5. Develop Scenarios

The purpose of this activity is to provide the operational concept behind a Use Case.

Process Steps

• Agree on the Format of a Scenario (See Appendix)

• Complete the draft Scenario for each Use Case

• Review with software test and system test organization

• Review with the training organizations

Output

• One Scenario is produced for one Use Case

6. Develop the draft GUI

To provide a draft of the GUI for the system, as envisioned during the development of Scenarios.

Process Steps

• Establish GUI project standards

• Develop draft GUI

• Provide the unique ID for each GUI

Outputs

• Draft GUIs

3. Process Script

2. Requirement Validation

   1. Documentation

After requirement elicitation has been complete, a document will be assembled to ensure that the requirements, from the developer’s perspective, are in-line with the wants and needs of the customer. A User Requirements Statement will be produced. It will have the following sections:

Introduction

High Level System Description

Context Diagram

Initial RTM

Stakeholders Table

Questions/Concerns

2. Customer Interaction

After the document has been produced it will be forwarded to the customer for their review. They will be responsible for reading the document to ensure that the requirements are correct and valid. They will make notes in the “Questions/Concerns” sections that will be addressed by the developers. The developers will respond to these questions and concerns. After all questions have been answered, another version of the User Requirements Statement will be produced for the customer. The developers will request that the customer “sign-off” on this document stating that all requirements for the desired system is in the document and that all requirements in the document are correct. If, for some reason, the customer still has concerns this process will be repeated until the customer will “sign-off” on the document.

2. Requirement Specification

In this section, the basic outline for an SRS will be described, as will many of the individual artifacts that comprise the SRS. The artifacts described in this section will make up the bulk of the completed SRS.

1. Process Description

At this point in the development process, it is hoped that all requirements have been identified and agreed to by both the customer and the development team. In addition, they should have been baselined, and should not change a great deal later in the development lifecycle (theoretically, at least). The artifacts described here are used to elaborate on the requirements and provide the software designers with a solid base with which to begin their work. It is at this point that the specific requirements are put to paper and that the system is broken down into components for later development.

Also at this point, the assembly of the actual SRS should begin. A general outline/table of contents for that document would be as follows:

1. Introduction

   1. Purpose

   2. Scope

   3. List of Definitions, Acronyms, and Abbreviations

   4. List of References

   5. Overview of the rest of the document

2. System Overview

2.1 Prose Restatement of the Problem Statement

2. Product Perspective (Context Diagram)

3. Product Functions (Shall Statements)

4. User Characteristics

5. Constraints

6. Assumptions and Dependencies

2. Specific Requirements

   2. Description of Component #1

   3. Description of Component #2

…

3.n Description of Component #n

2. Packaging (Description of what is required by the end of system development)

3. Appendix (RTM, ITL, PIP, TL, MRF, Use Case Diagrams, Review Documents, PPS, Configuration Management Data, DRL, Requirements Metrics, Planning Templates/Forms, Team members and Roles)

2. Tools and Techniques

The early phase of requirement specification varies depending on what specification/design methodology is to be used. For instance, if a structured approach were to be used, data flow diagrams and a structure chart would need to be created. If an object-oriented approach is being used, an object diagram needs to be made.

Also at this point, a state chart for the system could be created. This is especially useful for real-time systems, but may not be needed for other applications. IT is up to the engineers working on the project to decide if this is a worthwhile artifact to create.

Next, by completing templates for each software component of the system, the specification will become more complete and useful as a base for the next phase: design. The template used is called a Functional Specification Template or Class Specification Template (FST or CST). These forms, used in structured and object oriented design respectively, list all of the software functionality to be implemented. For structured design, these are listed simply as functions of the final program. For object oriented design, the functions are replaced by methods, which are in turn grouped into objects. In each case, the declaration (name and parameter list) for each function/method is listed. The structure chart or object diagram will serve as a guide for completing these templates.

After the FST’s or CST’s are completed, the RTM should be updated to show which requirements are covered in this section of the SRS. Also at this point, a thorough document review should be completed. Many, if not all, of the engineers working on the project should review the document and bring a list of suspected errors to a review meeting run by the Quality/Process Manager. Each engineer should be given a checklist prior to his or her individual review in order to guide the process.

3. Process Script

Tasks to be completed and this stage of requirements specification:

1. Completion of an FST or CST using a structure chart or object diagram as reference.

2. Begin writing the SRS using the provided outline as a guide.

3. Update the RTM to reflect what is included in the FST/CST.

Thorough SRS document review

Requirement management will ensure that as the SRS is developed, that the requirements in the SRS are valid. Throughout the SRS development process, new requirements emerge and existing requirements change. This is the reason for having a requirement management policy. There are three main concerns of requirements management:

1. Managing changes to agreed requirements.

2. Managing the relationships between requirements.

3. Managing the dependencies between the requirements document and other documents produced during the systems and software engineering process.

Requirement management supports almost all other requirements engineering activities, and therefore, it is carried out in parallel with them. Change management and traceability are the two topics of requirements management that will be the focus of this document and the SRS development process that has been previously defined.

Change management will deal with the first concern of requirements management. Traceability will deal with the second and third concerns of requirements management.

2. Requirement Verification

   1. Process Description

After the requirement document has been produced, the requirements should formally be verified. The verification process is concerned with checking the requirement for omissions, conflicts, and ambiguities and for ensuring that the requirements follow quality standards.

2. Process Guideline

   1. Check That The SRS Meets Your Standard

The purpose of this activity is to rapidly discover of non-compliance with standards

Process Steps

• Compare the structure of the requirement document with the defined standard and should highlight missing or incomplete sections.

• Check that all the pages are numbered and all the tables and figures are labeled

• If the deviations from the standard are found, return the document to the requirement team to correct those deviations (if there is enough time for a re-issue of document)

• If the deviations from the standard are found, but there is a tight deadline, note the deviations and distribute this to the document reviewer

Outputs

• The requirement document with the deviations from the standard are pointed out

2. Organize Formal Requirements Inspections

The purpose of this activity is to formally inspect the requirement document, to discuss the problems with the requirement and to agree on how these problems should be fixed.

Process Steps

• Form the group of the inspectors with the different backgrounds: should not been involved in the producing the requirement

• Use the check list (see Guideline 6.2.3) to help focus their attention on particular aspects of the requirements and requirement documents

• The group making decisions on actions to be taken to correct the identified problems

Output

• The filled Requirement Verification Checklist (RVC) with the agreed actions of fixing the problems

3. Define The Verification Checklists

The purpose of this activity is to help focusing on the verification process.

Process Steps

• The verification checklist should be concerned with the quality property of the requirements as a whole and with the relationship between individual requirements (see more detail in Sommerville and Sawyer 1998)

• The checklist should be expressed in a fairly general way and should be understandable by people such as end-users who are not system expert

Output

• The defined checklist template ( see Appendix )

3. Process Script

Appendices

Requirements Validation Checklist – Form RVC

Requirements Analysis Checklist – Form RAC

Requirements Elicitation Checklist – Form REC

Use Case xx : Title

Overview:

<Text that provides a high-level description of the Use Case>

Preconditions:

<List numerical the assumptions required before this Use Case can be executed>

Scenario:

Scenario Notes:

<Indicate concurrency of Actions, any additional information, such as operational steps and branching and iteration steps. When indicating same, refer to specific sequence number>

Post Conditions:

<List sequentially the conditions expected at the completion of the Scenario>

Required GUI:

<List the name of the GUIs utilized in this Scenario>

Exceptions:

< List sequentially any feature conditions that can be affect the Scenario, and how the system should respond>

Use Cases Utilized:

<List other Use Case used>

Timing Constraints:

<Specify any timing constraints for the Use Case or portion of the Use Case>

Sample Scenario Format

Requirement Change Request

page 2 of 2

List each change that will have to be made, and how the proposed changes will be implemented (only provide a high level description). Also rate if the change will be EASY, MODERATE, or DIFFICULT to implement.

__________________________________________________________________________________________________________________________________________________________________________ EASY MODERATE DIFFICULT

__________________________________________________________________________________________________________________________________________________________________________ EASY MODERATE DIFFICULT

__________________________________________________________________________________________________________________________________________________________________________ EASY MODERATE DIFFICULT

__________________________________________________________________________________________________________________________________________________________________________ EASY MODERATE DIFFICULT

Deciding Person(s): _____________________________ Date: _____/_____/_____

List the changes that will be implemented.

___________________________________________________________________________________________________________________________________________________________________________________________________________________________

___________________________________________________________________________________________________________________________________________________________________________________________________________________________

Deciding Person(s): _____________________________ Date: _____/_____/_____

List other documents that are associated with this change (include analysis documents, traceability documents, etc…) Also list tables, such as the RTM, that was changed due to this requirements change. Be specific as to what was changed!

Requirement Traceability Table

Requirement Traceabiliy Table Example and Explanation

R = one requirement; very briefly described

Requirement Relations

# - specifies/is-specified-by: This relation indicates that some requirement B adds detail to another requirement A.

* - required/is-required-by: This relation indicates that some requirement B requires the result provided by some other requirement A.

! - constrains/is-constrained-by: This relation indicated that some requirement B is constrained by some other requirement A.

Class Specification Template – Form CST

Functional Specification Template – Form FST

Functional Specification Template Instructions – Form FSTI

High Level Design Review Checklist – Form HDRC

High Level Design Review Checklist Instructions– Form HDRCI

Issue Tracking Log - Form ITL

Issue Tracking Log Instructions - Form ITLI

Process Improvement Proposal - Form PIP

Process Improvement Proposal Instructions - Form PIPI

Schedule Planning Template - Form SPT

Schedule Planning Template Instructions - Form SPTI

Task Planning Template – Form TPT

Task Planning Template Instructions – Form TPTI

Time Recording Log – Form TRL

Time Recording Log Instructions– Form TRLI

Inspection Report – Form IRF

Inspection Type:

Component Inspected:

Start Time: End Time:

Comments:

Review Team:

Name/Role

Brief Description of Meeting:

Appraisal of Inspected Project Component:

Defect Summary:

Supplementary Material Enclosed:

Defect Logs

Inspection Report Instructions – Form IRFI