Archive September 2018

Software Requirement and Their Types

Software Requirement and Their Types

A system or software requirement in simple terms is a condition or capability that somebody i.e a business / client needs or wants. It may be a distinctly new application or an enhancement feature of an existing application or the need of rectification of an existing error or limitation.

  • Conscious Requirement or Known Spoken –
    • Those, which the stakeholders of the proposed system believe to be necessary or essential.
  • Unconscious Requirement i.e forgotten or unspoken –
    • Those, which have not been mentioned by the stakeholders of the proposed system because they may not be required right at the present moment.
    • Those, which are unknown to some stakeholders and not spells out but needed by some other stakeholders who have not yet been consulted.
    • Those, which have already been satisfied by some of the existing processes manual or automated.
  • Functional Requirement –
    • Those, which specify what the proposed system has to do and traceable to specific source.
  • Non-functional Requirement –
    • Those, which are quality requirements, which specify how well the proposed system should do and what it is supposed to do such as
      • System performance
      • Availability
      • Reliability
      • Usability
      • Flexibility
      • Maintainability
      • Legal Issue related requirement

Process Steps Involved in Elicitation of Requirement

Process Steps Involved in Elicitation of Requirement:

  • Requirement inception: Relates to the use of context free questions
    • To establish the basic understanding of the problem,
    • To understand the people who wants the solution,
    • To understand the overall nature of the solution expected,
    • To gauge the effectiveness of the collaboration between customers and developers.
  • Requirement Identification: It Involves
    • Enlisting the basic well known and fairly defined needs
    • Articulating the basic well known and fairly defined needs
  • Requirement elicitation: Refers to finding out or extracting from the clients/ users
    • Requirements which are unclear, vague, or concealed and need explicit articulation for the understanding of the developer team.
    • About what the overall product/solutions objectives are.
    • About which needs are to be supported on priority.
    • About how the product / solution fits in to the business needs.
    • About what kind of use will be made of the product/solutions on day to day basis.

Quality Requirement Elicitation

Quality Requirement Elicitation:

While Gathering requirements, attention should be paid to ensure that quality requirements are gathered during the elicitation process. Every requirement should confirm to the following quality norms:

  • Correctness – The correctness of the requirement should be confirmed with the client’s stakeholders.
  • Feasible – The requirement should be deliverable by making use of available tools, technique, method and people, within budget and time.
  • Necessary – With respect to undertaking, the development and immediate implementation for meeting the basic needs of the client, the ranking of the feature should be of relatively high importance.
  • Prioritized – With respect to priority scale, the ranking of the feature should be one of relatively high importance.
    • Requirements, if very important, should be immediately included in the present release of the proposed system.
    • Requirements, if absolutely necessary should be essentially implemented in the next release.
    • Requirements, if important but not necessary, should be conditionally included in next release.
    • Finally, requirements if purely optional, their implementation should depend upon the constraints of the resources and schedule.
  • Unambiguous – The requirement should be easy to read and understood by all.
  • Concise – The requirement should be brief or short or to the point with only the relevant information. It should be mixed up with other details related to project scope parameters or background.
  • Verifiable – The implementation of the requirements in the end product or software deliverable should be testable and measurable by human or mechanized means.

Requirement election methods – Interview

Requirement election methods – Interview

Interview – Interviewing is the most commonly used requirement elicitation technique used usually in conjunction with almost all of the other method. It involves the following steps described in detail as under.

  • Creating questions – Firstly, this step involves taking the inputs from project documents to seek background information. Next, it involves the preparation of relevant set of questions which will be able to uncover knowledge and reveal true requirements on what is needed, rather than what is wanted or thought to be needed. All questions and answer should be documented so it can be use for future analysis.
  • Selecting Interviewees – This involves identification of representative from stakeholders groups based on their background. The entry level personnel often provide fresh perspective and unexpected pearls of information. The mid-level stakeholders provide useful insight into the operational or technical aspect of the domain due to their experience. The managers or special customers, having deeper knowledge of domain and understanding of the success project criteria so they provide valuable input which is vital. The varied backgrounds of the stakeholders provide help in verifying the reliability of collected information.
  • Planning Interview session – Before planning the sessions, a background check of each of the representative stakeholders is useful. It provides an understanding of each individual’s personality, orientation, contribution, achievements and stake in the project. Main focus should be on identifying oneself, clarifying purpose, indicating process by which the interviewee was chosen. Emphasizing on need for face to face discussion, contact details should be conveyed to facilitate interviewee to revert back in case of any problem requiring reschedule of the session.
  • Closing meeting – care should be taken before closing the meeting to keep the morale of the interviewee high so that cooperation could be sought in future too. Before concluding the interview, it should be inquired if the interviewee has any questions. Any documents or artifacts, copies of which could be needed for further analysis.
  • Planning Future course of action – Follow up action, by formally thanking the interviewee for his/her participation should be sent as soon as possible after the interview. The findings should be properly documented. Future Planning for requirement specification.


Requirement election methods – Brainstorming

Requirement election methods – Brainstorming

Brainstorming is a technique, which involves a group of people during the requirement gathering process. This method is adopted for various purposes such as for defining the problem to be solved, arriving at the requirement specification, analyzing and modelling the requirements and evolving the design of the software to be developed.

It involve following steps

  • Roles – Normally participants are categorized as per their roles.
    • There is a leader designated for the entire group who act as a facilitator or moderator. He is the person who defines the agenda, sets the brainstorming session rolling, encouraging, motivating and leading the discussion.
    • There is a person designated as a scribe, who records all ideas in a manner visible to all using flip charts, white board, transparencies or computer presentation.
    • There are participants, usually limited to less than ten persons, representing the stakeholders who voice their ideas, listen to others.
  • Rules – Various rules are usually framed for the collection of the brainstorming session, depending on the roles of the participants.
    • The leader should allow all ideas to be expressed freely without criticism, prevent judgement, establish decorum, set time limits, and establish focus on purpose.
    • The scribe should capture essence of ideas – not descriptions, write ideas in short summaries form as stated, seeking clarification if required.
    • The participants should contribute their own ideas – not picking a lead form of others. They should be creative, imaginative and apply fast thinking.
  • Guidelines – Various guidelines have been proposed by experts to ensure the success of brainstorming sessions such as
    • Allowing group members to decide on breaks, arranging for refreshment, setting the mood for the session right using light humor at the beginning, restricting the session for two hours.
    • Creating trust and report for letting creative ideas being freely expressed while session.
    • The essential project document and rules of the session should be made available to all participants well in advance.
  • Agenda – The agenda for brainstorming session could be on the following lines.
    • First the purpose and objective of the session should be made clear to all, explaining the rules and introducing all participants.
    • This should be followed up by a warm up activity of around 10 minutes to establish the right mood for all participants on a topic commonly understood by all but unrelated to agenda.
    • After this, the actual brainstorming activity should commence. Ask participants to quickly come up with ideas in relation to finding ways of solving problems in line with ideas in relation to finding ways of solving problems in line with the core purpose and objectives. After an intensive session of 10 to 15 minutes call for a break before resume once again.


Business Requirement Specification

Business Retirement Specification Template


<enter project name>

Business Requirements Document


Document Instructions

<This document template contains directions for use or sample entries. These directions are enclosed in brackets  and are italicized. They are included to help you fill out the form. As you complete the form, delete these instructions.

Please follow this document naming convention to facilitate document search and retrieval:

 <project code (if appropriate)>  <project name (abbreviated)>  <document name (abbreviated)>  <version (if appropriate)>

 All documents should be posted to the appropriate project folder in SharePoint. >

Document History

<The document history is a log of changes that are made to the document, who made the changes, and when.  For example, the initial creation of the document may contain the following:  Version 0.1, Date 1/1/2004, Author Charlie Brown, Status Initial creation.  Subsequent updates to the document will be Version 0.2, 0.3, etc.  The first published version of the document should be Version 1.0.>

Version Date Author Status Section Revision Description
0.1 Initial Draft
1 First Published


 <The required approvals for this document are outlined in the project Change Management Plan. SharePoint workflow approvals may be used In lieu of this Approval section. If utilizing SharePoint, attach this document to the Change Request list item. If utilizing the document, distribute the document and request electronic signatures to indicate approval.

Copy additional signature line and details as needed>

 Your signature below indicates that this document meets its objectives and is acceptable.

Signature Signature
<Name> <Name>
<Date> <Date>
<Title> <Title>
<Role> <Role>


Table of Contents


2 .Glossary and Acronyms

3. Executive Summary

3.1. Background


3.3.In Scope

3.4. Out of Scope

4 . Requirements Elicitation and Gathering

4.1. Approach Overview

4.2. References/Inputs

5. Business Model

5.1. Organizational Profile

5.2. High Level ‘As-Is’ Process Flow

5.3. High Level ‘To-Be’ Process Flow

5.4. Process Mapping

5.5. Gap Analysis.

6. Requirements Definition

7. Appendix


Now I am going to discuss about each paragraph in detail.


The purpose of the Business Requirements Document (BRD) is to lay the foundation for the design and development of a technical solution through definition of the business’ needs and achieve the goals and objectives of the <enter project name> project. The BRD describes the high-level business process and outlines the business needs that will be fulfilled by the successful completion of the project. In combination with the Requirements Traceability Matrix (RTM), it identifies actual technical or system requirements for the solution.

The foundation for a successful project is built upon the quality and thoroughness of requirements gathering. The BRD establishes key requirements, objectives, and goals that drive all other subsequent lifecycle phases. The RTM describes the business problem to be solved in terms of verifiable and traceable characteristics and constraints. In addition to key program level requirements, the requirements capture operational concepts and program level interfaces. The RTM should be continuously referenced during the project lifecycle phases to ensure that the deliverables from the project meet the approved requirements.

Signoff requirements of the BRD, inclusive of the RTM, are defined in the project’s Change Management Plan. Approval by the project sponsor ensures the requirements will support achieving the project’s goals and objectives.

2. Glossary and Acronyms

<A general list of common terms and acronyms are listed. Provide any project-specific terms or acronyms that may be used within this document; remove any that do not apply.>

Table: Terms and Acronyms Used in This Document

ALS Ambulance Licensure Service
BIIT Bureau of Informatics & Information Technology
BEMS Bureau of Emergency Medical Services
BRD Business Requirements Document – Details the business solution for a project including the documentation of customer needs and expectations.

<If a project charter does not exist, this section is intended to provide a brief, one-page summary describing the purpose, background, objectives, and scope for the overall project. Sign-off of the document provides a foundation for the project team and base criteria for decision-making, prioritization, and issue resolution.

3. Executive Summary

 Delete this section if the project has an approved charter.>

[Enter the Executive Summary text here]

3.1. Background

<Provide high-level description of the problem/opportunity which originated the project.>

[Add text here].

3.2 .Objectives

<List top 3-5 objectives, including success criteria/measurements>

[Add text here].

3.3. In Scope

<List top processes, features, and/or functions addressed by the project>

[Add text here].

3.4. Out of Scope

<List top processes, features, and/or functions NOT addressed by the project>

[Add text here].

4. Requirements Elicitation and Gathering

4.1. Approach Overview

< In this section, provide a summary describing the approach, methods, and documentation of the business requirements, including: project drivers, key project stakeholders, main functions that will be performed by the system, and a general requirements documentation timeline.>

[Add text here].


<Identify the sources of information/reference materials that were used to develop the Requirements Plan, such as:

  1. Author name, title, and publication date.2. Author name, title, and publication date.>

[Add text here].

5.Business Model

<Describe the current environment in detail to help identify and support the needs and goals described in the previous section.  Consider the following list of questions to help define the current environment

  • What are the current problems faced (without the system) today?
  • What problems should this system solve?
  • Do you have to do things manually that you would like to automate?
  • Do you have performance problems that need to change?
  • Do you have functional limitations that you would like to change?
  • Are you using packages that force you to constrain your business functionality to the boundaries of the package?>

[Add text here].

5.1. Organizational Profile

<Describe the organizational entities (program area, bureau, etc.) that are involved in or will be affected by the system being developed or modified. At a minimum, answer these questions: Who (including titles and roles) will be using the system? What are their levels of expertise?>

[Add text here].

 5.2 . High Level ‘As-Is’ Process Flow

<A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow diagram here].

 5.3.High Level ‘To-Be’ Process Flow

<This section should include an introduction describing the major functional areas of the system from users’ perspectives.  If the new system has been segmented into subsystems, the functional requirements are defined by subsystems.  The project team defines, by subsystems, those functions which the new system must perform in order to achieve the objectives and realize the benefits >

 <A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow graphic here.

 5.4      Process Mapping

<Processing Mapping allows the reader to quickly see how the current functions will be addressed by the proposed solution.  This can be done in narrative form or can be depicted in a table format.  This method is especially useful if there are multiple system modules or multiple systems within a solution.

[Add text or table here]

5.5. Gap Analysis

<A gap analysis compares the ‘as-is’ and ‘to-be’ processes and identifies which functional areas may not be fully addressed by the solution.  Recommended mitigating strategies and/or business process redesign should also be included.>

[Add text here]

6. Requirements Definition

To ensure traceability throughout the project lifecycle and adherence to the change management process, each detailed requirement for the project is defined within the RTM.

Requirements usually reflect a need from the business/program area and is a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer or other stakeholder. A requirement may include technical components if there is a specific business need associated with a technology platform, approach, or solution.

<Please refer to the PMM templates to access the RTM tool.  Please delete the descriptive text and insert a link to the RTM or embed the document here.>

7 . Appendix

<In this section add any additional information relevant to this document’s subject matter. >

[Enter text here]


What is Software Requirement Specification?

Software Requirement Specification

SRS describe entire system flow, overall functionality of the system, how the data will flow within the system. It describes each module functionality.

SRS also include use cases that explain user interaction with the system or software. It also describe non- functional requirements like security, availability etc.


Software Requirement Specification Template


Software Requirement Specification


<Project Name>

Version <X.X>


Prepared By
Name Designation email
Xxxxx xxxxxx Business Analyst [email protected]
Yyyyy yyyyy Project Manager [email protected]


Revision History
Name/Author Date Reason For changes Version



  1. Introduction. 2

1.1.       Purpose. 2

1.2.       Scope. 3

1.3.       Assumption and Dependencies. 3

1.4.       Overview.. 3

  1. General Description. 3

2.1.       Product Perspective. 3

2.2.       Product Functions. 3

2.3.       User characteristics. 3

2.4.       General Constraints. 4

2.5.       3.0. Specific Requirements. 4


1.     Introduction

Under the subsections of this section, an overview of the SRS is provided which can be deemed as an executive summery.

1.1. Purpose

Under this subsection the following aspect of SRS developed are mentioned in a brief manner.

  • The overall purpose of document.
  • The reason of its creation
  • Identity of the stakeholders for whom it is addressed.

1.2. Scope

Under this subsection, the following aspects of the overall software to be developed are mentioned in a briefs manner

  • Main Functions
  • What it will do?
  • What it will not do?
  • How it will be used?
  • Benefits
  • Objectives
  • Goal

1.3. Assumption and Dependencies.

Under this subsection, the factors influencing the requirements under the SRS are explained.

  • List of Factors
  • A brief description of each factor

1.4. Overview

Under this subsection, the structure of SRS document is described with reference to

  • The topic covered.

2. General Description

Under the subsections of this section, the general factors which affect the proposed software to be developed, and its requirements are mentioned.

2.1. Product Perspective

Under this subsection, nature of the software product to be developed is mentioned.

  • Nature of product
  • Functions(If a component or subsystem)
  • Identified Interconnection(if a component or subsystem)
  • Block diagram of product and its relationship with the external and internal environment.

2.2. Product Functions

Under this subsection, function of the software product are described in terms of

  • List of function performed.
  • Summary description of each function
  • An explanatory block diagrams of the function with their interrelationship.

2.3. User characteristics

Under this subsection, the characteristics of the user of product which affects requirements are mentioned in terms of

  • Classes of users.
  • Characteristic of each user class in terms of experience and technical expertise.

2.4. General Constraints

Under this subsection, the various constraints which influences the design and development of the proposed software product are mentioned i.e,

  • Regulatory Policies
  • Hardware Limitation
  • Interface to other application
  • Safety and security consideration.

3. Specific Requirements

Under the subsection of this section, the details of the requirements are elaborated to facilitate the developer to create the software design documents before commencing the coding activity. Attention is focused on following in this context

  • Individual requirements are defined keeping in mind quality characteristics.
  • Source of each requirement is defined and referenced properly.
  • All requirements are organized in a structured and logical manner.

3.1. Functional requirement

Under this subsection, all functional requirements which need to be implemented in relation to the product are specified.

3.1.1. Purpose

Under this, the rationale and intent of including the functional requirement is clarified.

3.1.2. Input

Under this input values which will be accepted by the product as input in context of the functional requirement are elaborated in terms of the source, valid range, timings, Operator requirements, and special interfaces required.

3.1.3. Operations

Under this the operations which will be performed by the product to transform the input in context of the functional requirement are elaborated in terms of the validity checks, response to abnormal conditions and type of processing required.

3.1.4. Outputs

Under this the output which will be generated by the product after processing the input, in context of the functional requirement are elaborated in terms of the destination, valid range, timing, handling of illegal values, error messages and special interface required.

3.2.External Interface requirements

Under this subsection, all the interfaces to the external entities which need to be implemented by designer specified in relation to the software product as under.

3.2.1.  User Interface

Under this the characteristic of the interface for the human interaction with the software product are specified in terms of screen format, layout, menus, relative timing for input  and outputs, programmable function keys, a list do’s and don’ts on how the system will appear to the user.

3.2.2. Hardware Interface

Under this, the logical characteristics of the interface between the software product and various hardware components are specified in terms of which device will supported, how they will be supported, block diagrams depicting the relationship between the hardware components and the software functions.

3.2.3.  Software Interface

Under this, the logical characteristics of the interface between the software product and various other eternally required software products are specified in terms of the technical name, version number, manner of communication in terms of message content and format.

3.2.4. Communication Interface

Under this, the various interfaces between the software product and various communication and network protocols are specified in terms of local network protocol.

3.3. Performance Requirement

Under this subsection, the details of the performance related requirement placed on the software product or the human interaction with the software product.

  • Static numerical requirements such as number of terminals, simultaneous users, files and records, size of tables and files.
  • Dynamic numerical requirements such as number of transactional task and amount of data to be processed within the time limits under normal and peak workload conditions.

3.4. Design Constraints

Under this subsection, the details of requirement placed on the software product as constraints which need to be taken in the account.

3.4.1. Standard compliance

Under this, the requirement related to existing standard and regulations which need to be compiled with the software product such as report formats, data naming convention etc..

3.4.2. Hardware Limitation

Under this, the requirement related to various hardware constraints and operating environment  which need to compiled with by the software product are specified.

3.5. Quality Characteristic

Under this subsection, quality requirement places on the software product as constraint.Relevent quality characteristic are selected from generic one such as correctness, efficiency, flexibility, security, maintainability, portability, reliability and usability.

3.6. Other Requirements

3.6.1.   Database
Under this the specific requirements of any database which need to be developed as a part of the software product are specified such as
  • Type of information to be used
  • Frequency of use
  • Accessing capabilities
  • Data elements and file description
  • Relationship between data elements, records and files.
3.6.2. Site Adaption Requirement

Under this the specific requirements related to any specific installation site environment which need to be supported by the software product are specified such as

  • Data or installation sequence specific to any site, mission or operational modes e.g safety mode.
  • Any customized software product features modification required for a specific site.

4. Supporting Information

Under the subsection of this section, all supporting information is included to ensure the completeness of the SRS such as

4.1. Definition, acronyms and abbreviation

Under this subsection, the meaning and definition of all keywords and short form used in the SRS document are given to facilitate proper interpretation with reference to appendix or other documents.

4.2.  References

Under this subsection, the list of documents reference in the SRS along with the title, reference id, date, author, document resources and web resources are given including the traceability table.

Find Below link to download SRS template.

SRS Template

Guidance for Use Case Document


Use Case Document


<Project Name>


Prepared by <author>


<date created>

Revision History

Name Date Reason For Changes Version

 Guidance for Use Case Template

Document each use case using the template shown in the Appendix. This section provides a description of each section in the use case template.

1. Use Case Identification

1.1.Use Case ID

Give each use case a unique numeric identifier, in hierarchical form:  X.Y. Related use cases can be grouped in the hierarchy. Functional requirements can be traced back to a labeled use case.

1.2. Use Case Name

State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some examples:

  • View part number information.
  • Manually mark hypertext source and establish link to target.
  • Place an order for a CD with the updated software version.

1.3. Use Case History

1.3.1 Created By

Supply the name of the person who initially documented this use case.

1.3.2  Date Created

Enter the date on which the use case was initially documented.

1.3.3 Last Updated By

Supply the name of the person who performed the most recent update to the use case description.

1.3.4  Date Last Updated

Enter the date on which the use case was most recently updated.

2. Use Case Definition

2.1. Actor

An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor(s) that will be performing this use case.

2.2. Description

Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the use case.

2.3. Preconditions

List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. Examples:

  1. User’s identity has been authenticated.
  2. User’s computer has sufficient free memory available to launch task.

2.4. Postconditions

Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples:

  1. Document contains only valid SGML tags.
  2. Price of item in database has been updated with new value.

2.5. Priority

Indicate the relative priority of implementing the functionality required to allow this use case to be executed. The priority scheme used must be the same as that used in the software requirements specification.

2.6. Frequency of Use

Estimate the number of times this use case will be performed by the actors per some appropriate unit of time.

2.7.  Normal Course of Events

Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I <accomplish the task stated in the use case name>?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system.

2.8. Alternative Courses

Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example:  X.Y.AC.1.

2.9. Exceptions

Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason. Number each exception using the Use Case ID as a prefix, followed by “EX” to indicate “Exception”. Example:  X.Y.EX.1.

2.10. Includes

List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality.

2.11. Special Requirements

Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.

2.12. Assumptions

List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description.

2.13. Notes and Issues

List any additional comments about this use case or any remaining open issues or TBDs (To Be Determineds) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is.


Use Case document Template

Use Case Template:

Use Case ID:  
Use Case Name:  
Created By:   Last Updated By:  
Date Created:   Date Last Updated:  


Frequency of Use:  
Normal Course of Events:  
Alternative Courses:  
Special Requirements:  
Notes and Issues: