Project scope is the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions. Scope Plays a Vital Role in Projects. "Scope" includes the expected work effort and results for a given project, and must be documented and accepted before the project begins.

1.2 How Scope is usually defined

Defining the project scope is a challenging job. All projects are defined by their goals, objectives, boundaries and constraints. Getting a detailed but clear picture of your project scope will put you toward completing your project successfully.

Goals and objectives define what has to be done. A goal is simply a broad statement of what you want to do. The objectives are sub-goals, more detailed, that explain what must be done to achieve the goal. Your project should have only one goal, but may have several objectives.

Here is an example of a goal with several objectives.

· Goal (more broad): We want to move the office to Houston, Texas.

· Objective (more specific): Locate an office in Houston.

· Objective (more specific): Arrange for personnel and equipment transfer

· Objective (more specific): Transfer equipment and furnishings

· Objective (more specific): Transfer personnel

· Objective (more specific): Maintain business-as-usual during the transition

Project Boundaries identify inclusions and exclusions -- things that we do or don't want to do in conjunction with the goals and objectives. These are things that may not be related to the project, but that must be considered anyway. For example:

· Personnel not wishing to transfer will be replaced and arrangements made for outplacement.

· Company vehicles will be sold and replaced with new ones in Houston.

· Disposal of current facilities is not part of this project.

Project Constraints define cost, schedule, or quality requirements. These may include budget limitations or schedule requirements or minimum acceptability. For example:

· The cost of the entire move can't exceed 50,000.

· The move must be completed during the month of June, next year.

· Payments on outplacement services can't exceed 1200 per employee.

· The new Offices must support 200 office workers.

1.3 Write a scope statement

A comprehensive scope statement is a key section. It is an agreement that defines the work of the project and the customer's business objectives. A comprehensive scope statement can help you identify changes in scope after the project has started and help you plan for any modifications or adjustments that might be needed during the life cycle of the project.

A well-written scope statement is crucial to a project. You create a project scope statement to establish a solid agreement between the project team and the customer by clarifying, identifying, and relating the work of the project to the business owner's objectives. The two parties reach an agreement by explaining the need or issue to be resolved by the project, what the product or deliverables will include, and what potential costs, gains, and success measures are involved.

Writing a successful scope statement means that you include:

· Project justification

· Project product

· Project deliverables

· Project objectives

You should have the scope statement reviewed and approved by the both the project sponsor and the customer.

To write a scope statement, include the following criteria:

1.3.1 The project justification information

The project justification describes a problem to be resolved, an opportunity to be exploited, or a benefit to be obtained. You always derive the project justification from the strategic objectives of the parent organization. The following are examples of project justification:

· Market demand

· Business need

· Customer request

· Technological advance

· Legal requirement

The project justification needs to be clear and precise, and you should include both qualitative and quantitative measures.

1.3.2 Identify the project product

Define possible solutions to your problem (for example, the project justification); specifically, identify the solution that you selected for your project. The project product is a summary of the product description and includes:

· Work required to resolve the problem and achieve the benefits.

· Work that falls outside the project scope.

· Interactions with other projects.

It is crucial that you identify work that might fall outside or inside the project scope. Identifying the inclusion and exclusions is important because it enables you to set expectations with your customer and project team.

Note: If you clearly identify exclusions at the beginning of a project, future projects are more easily identified.

1.3.3 Identify the project deliverables

List the summary-level sub deliverables of the project for which full and satisfactory delivery would mark the completion of the project. These include the project deliverables and the high-level Work Breakdown Structure (WBS).

Rather than breaking the work of the project into a list of low-level deliverables and details, identify high-level deliverables so that project reviewers can readily focus on the business problems that the project is trying to resolve.

1.3.4 Identify the project objectives

Identify project objectives that you can define as quantifiable criteria.

The project objectives must:

· Address all the work within the scope of the project.

· Not address work outside the scope of the project.

Note: Unquantifiable objectives, such as customer satisfaction, involve high risk.

1.4 Sample Scope Statement [3]

Project Title: Project Management Intranet Site Project

Project Justification: Joe expertise to current and potential clients though the sections of the intranet that will be accessible to them. It will also help improve profitability by reducing internal costs by providing standard tools and techniques, templates, and project management knowledge to all internal consultants.

Product Characteristics/Requirements:

1. Templates and tools: The intranet site will allow authorized users to download files to assist them in created project-management documents and using project management tools. These files will be in Microsoft Word, Excel, Access, Project, html, or PDF format, as appropriate.

2. User submissions: Users will be encouraged to e-mail files with sample templates and tools to the Webmaster. The Webmaster will forward the files to the appropriate person for review and then post the additional files, if desired.

3. Articles: Any articles posted on the site will have appropriate copyright permission. The preferred format for articles will be in PDF files. The project manager may approve other formats.

4. Requests for articles: The intranet site will include a section for users to request someone from the Project Management Office (PMO) at JWD Consulting to research appropriate articles for them. The PMO manager must first approve the request and negotiate payments, if appropriate.

5. Links: All links to external sites will be tested on a weekly basis. Broken links will be fixed or removed within five working days of discovery.

6. The “Ask the expert” feature must provide a user-friendly screen to solicit questions, immediate acknowledgement that the question has been received in the proper format, forwarding of the question to the appropriate expert, as maintained in the system’s expert database, and status of answering the question. The system must also allow for payment for advice, if appropriate.

7. Security: The site must provide several levels of security. All internal employees will have access to the entire site when they enter their security information for the main corporate intranet. Part of the site will be available to the public from the corporate Web site. Other portions of the site will be available to current clients based on verification with the current client database. Other portions of the site will be available after negotiating a fee or entering a fixed payment using pre-authorized payment methods, as described in Appendix A.

8. Search feature: The site must include a search feature for users to search by topic, key words, etc.

9. The site must be accessible using a standard Internet browser. Users must have appropriate application software to open several of the templates and tools.

10. The site must be available 24 hours a day, 7 days a week, with one hour for system maintenance and other periodic maintenance, as appropriate.

Summary of Project Deliverables:

Project management-related deliverables: (business case, charter, team contract, scope statement, WBS, schedule, cost baseline, status reports, final project presentation, final project report, lessons learned report, etc.)

Product-related deliverables:

1. Survey: Survey current consultants and clients to help determine desired content and features for the site.

2. Files for templates: The initial site will include templates for the following items: (business case, charter, etc.)

3. Examples of completed templates: The initial site will include examples of projects that have used templates for the following items: business case, charter, etc.

4. File for tools: The initial site will include information on how to use several project management tools, including, as a minimum, the following: work breakdown structures, critical path analysis, cost estimates, earned value management, etc. Where appropriate sample files will be provided in the application software appropriate for the tool.

5. Example applications of tools: The initial site will include examples of projects that have applied tools for the following items: work breakdown structures, critical path analysis, cost estimates, earned value management, etc.

6. Articles: The initial site will include at least ten useful articles about relevant topics in project management.

7. Links: The initial site will include links along with brief descriptions of the site being linked to for at least twenty useful sites. The links will be categorized into meaningful groupings.

8. Expert database: In order to deliver an “Ask the Expert” feature, the system must access a database of approved experts, their contact information, etc.

9. User request: The site will include an application to solicit and process requests from users.

10. Intranet site design: An initial design of the new site will include a site map, suggested formats, appropriate graphics, etc.

11. Intranet site content: The initial site will include content for the templates and tools section, articles section, links section, “Ask the Expert” section, user requests, security, and payment features.

12. Test plan: The test plan will document how the site will be tested, who will do the testing, how bugs will be reported, etc.

13. Site promotion: A plan for promoting the new site will describe various approaches for soliciting inputs while designing the site as well as announcing the availability of the new site.

14. Project benefit measurement plan: A plan for measuring the financial value of the site.

Project Success Criteria: Our goal is to complete this project within six months for no more than 140,000. The project sponsor, Joe Fleming, has emphasized the importance of the project paying for itself within one year after the site is completed. In order to meet this financial goal, the site must be designed with strong user inputs, and we must develop a method for capturing the benefits of the site while it is being developed, tested, and after it is rolled out. If the project takes a little longer to complete or costs a little more than planned, it will still be viewed as a success if it has a good payback and helps promote our company’s image as a world-class consulting organization.

Reference:

1. http://office.microsoft.com/en-us/project-help/write-a-scope-statement-HA001142472.aspx

2. http://www.managingsmallprojects.com/define-the-project-scope.html

3. www.augsburg.edu/ppages/~schwalbe/scope_statement.doc

2. Functional and Non Functional Requirement

2.1 Software Requirements Definitions

Before talking about the requirement process in general and discussing different tools and techniques used for developing a good set of requirements, let us first look at a few definitions of software requirements.

Jones defines software requirements as a statement of needs by a user that triggers the development of a program or system.

Alan Davis defines software requirements as a user need or necessary feature, function, or attribute of a system that can be sensed from a position external to that system.

IEEE defines software requirements as:

A condition or capability needed by user to solve a problem or achieve an objective.

A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

As can be seen, these definitions slightly differ from one another but essentially say the same thing: a software requirement is a document that describes all the services provided by the system along with the constraints under which it must operate.

2.2 Importance of Requirements

Many of the problems encountered in development are attributed to shortcoming in requirement gathering and documentation process. We cannot imagine start building a house without being fully satisfied after reviewing all the requirements and developing all kinds of maps and layouts but when it comes to software we really do not worry too much about paying attentions to this important phase. This problem has been studied in great detail and has been noted that 40-60% of all defects found in software projects can be traced back to poor requirements.

Fred Brooks in his classical book on software engineering and project management “The Mythical Man Month” emphasizes the importance of requirement engineering and writes:

Let us try to understand this with the help of an analogy of a house. If we are at an advanced stage of building a house, adding a new room or changing the dimensions of some of the rooms is going to be very difficult and costly. On the other hand if this need is identified when the maps are being drawn, one can fix it at the cost of redrawing the map only. In the case of a software development, we experience the exact same phenomenon - if a problem is identified and fixed at a later stage in the software development process, it will cost much more than if it was fixed at and earlier stage.

2.3 Role of Requirements

Software requirements document plays the central role in the entire software development process. To start with, it is needed in the project planning and feasibility phase. In this phase, a good understanding of the requirements is needed to determine the time and resources required to build the software. As a result of this analysis, the scope of the system may be reduced before embarking upon the software development.

Once these requirements have been finalized, the construction process starts. During this phase the software engineer starts designing and coding the software. Once again, the requirement document serves as the base reference document for these activities. It can be clearly seen that other activities such as user documentation and testing of the system would also need this document for their own deliverables.

On the other hand, the project manager would need this document to monitor and track the progress of the project and if needed, change the project scope by modifying this document through the change control process.

2.4 Levels of Software Requirements

Software requirements are defined at various levels of detail and granularity. Requirements at different level of detail also mean to serve different purposes. We first look at these different levels and then will try to elaborate the difference between these with the help of different examples.

2.4.1 Business Requirements:

These are used to state the high-level business objective of the organization or customer requesting the system or product. They are used to document main system features and functionalities without going into their details. They are captured in a document describing the project vision and scope.

2.4.2 User Requirements:

User requirements add further detail to the business requirements. They are called user requirements because they are written from a user’s perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements. They are captured in the requirement definition document.

2.4.3 Functional Requirements:

The next level of detail comes in the form of what is called functional requirements. They bring-in the system’s view and define from the system’s perspective the software functionality the developers must build into the product to enable users to accomplish their tasks stated in the user requirements - thereby satisfying the business requirements.

Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing and other specific functionality. They are supported by non-functional requirements, which impose constraints on the design or implementation (such as performance requirements, security, quality standards, or design constraints). Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform.

Typically, a requirements analyst generates functional requirements after building use cases. However this may have exceptions since software development is an iterative process and sometimes certain requirements are conceived prior to the definition of the use cases. Both artifacts (use cases documents and requirements documents) complement each other in a bidirectional process.

A typical functional requirement will contain a unique name and number, a brief summary. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system.

The core of the requirement is the description of the required behavior, which must be a clear and readable description of the required behavior. This behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements will be uncovered during the use case development. When this happens, the requirements analyst should create a placeholder requirement with a name and summary, and research the details later, to be filled in when they are better known.

Software requirements must be clear, correct, unambiguous, specific, and verifiable.

Functional requirements are typically phrased with subject/predicate constructions, or noun/verb. "The system prints invoices."

Non-functional requirements may be found in adverbs or modifying clauses, such as

"The system prints invoices *quickly*"

"The system prints invoices *with confidentiality*".

From a mathematical point of view, a "function" takes an input(s) and yields an output(s). "Functional" refers to the set of functions the system it to offer, while "non-functional" refers to the manner in which such functions are performed.

Following are IEEE definitions:

Functional requirement: A system/software requirement that specifies a function that a system/ software system or system/software component must be capable of performing.

These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.

Functional Requirements are a key area of project management and they are very important system requirements in the system design process. These requirements are the technical specifications, system design parameters and guidelines, data manipulation, data processing, and calculation modules etc, of the proposed system.

Functional Requirements are in contrast to Non-Functional Requirements which are descriptive of the parameters of system performance, quality attributes, reliability and security, cost, constraints in design/implementation, etc. The key goal of determining “functional requirements” is to capture the required behavior of a system in terms of functionality.

Listed below are a total of fifty examples of functional requirements. These examples are from five basic systems:

· Accounts Payable

· Purchasing

· Sales

· Human Resources

· Finance

Accounts Payable

The following is a running list of possible Accounts Payable functional requirements examples:

· Supports three way matching - purchase order, receipts, and supplier invoices

· Supports the option to place an individual invoice on hold

· Allows for modifications to invoice account distribution after processing

· Supports the partial payment of invoices

· Supports the vendor payments without purchase orders

· Vendor return processing is fully integrated with the warehouse and accounts payable functionality

· Vendor return processing provides the user the ability to tie the return to a specific purchase order

· Vendor return processing supports return of roods received against closed purchase orders

· Supports the linkage of the return's debit memo to a single purchase order

· Supports basic Internet based purchasing functionality

Purchasing

The following is a running list of possible Purchasing functional requirements:

· Supports user defined vendor types

· Supports unique vendor address and contact information for vendor corporate address, remit to address, and ship to address

· Supports automatic purchase order generation default by vendor

· Supports minimum and maximum receipt allowances by vendor

· Supports tracking of last price paid for an item

· Supports calculation of purchased price variances (PPV)

· Supports online inquiry or report to compare actual vs. expected purchase costs

· Allows purchase order price to default to last amount paid

· Tracks vendor performance on late deliveries

· Tracks vendor performance on order fill rates

Sales

The following is a running list of Possible Sales functional requirements:

· Application must capture appropriate information and produce comparative analysis reports

· Application must capture appropriate information and produce trend analysis reports

· Trend analysis by customer and product, including profitability by customer

· Monthly detail by customer and invoice

· Graphic trend charts by customer, salesman, product type, and others Sales of products by vendor, by zip code.

· Sales by source code (for mail order companies)

· Sales analysis by state

· Daily activity report

Human Resources

The following is a running list of Possible Human Resources functional requirements:

· Tracks employee sick and personal time allowed versus time taken

· Supports the tracking of individual employee date of hire and anniversary dates

· Supports the tracking of time and attendance reporting for hourly employees

· Supports the tracking of time and attendance reporting for salary employees

· Supports integration of time and attendance functionality to the manufacturing plant floor schedule

· Supports printing of payroll checks

· Supports the tracking of federal payroll tax processing

· Supports the tracking multi-state and providence payroll tax processing

· Federal, state, and providence based payroll tax tables are included with Software Sale and Post-Sale Updates Provided

· Supports employee tax accruals and reports

Finance

The following is a running list of Possible Finance: General Ledger functional requirements:

· Supports user defined general ledger account structure

· Allows two or more accounting periods to be open at one time

· Allows for automatic period close processing

· Supports the automatic close of income and expense accounts to retained earnings

· Supports automatic year-end processing

· Allows the user to run year-end more than once

· Standard report for chart of accounts

· Standard report for comparative balance sheets for individual period review

· Standard report for cash flow

· User defined financial reports

· Allows prior period adjustment

2.5 Non-Functional Requirements

Non-functional requirement play a significant role in the development of the system. If not captured properly, the system may not fulfill some of the basic business needs. If proper care is not taken, the system may collapse. They dictate how the system architecture and framework. As an example of non-functional requirements, we can require software to run on Sun Solaris Platform. Now it is clear that if this requirement was not captured initially and the entire set of functionality was built to run on Windows, the system would be useless for the client. It can also be easily seen that this requirement would have an impact on the basic system architecture while the functionality does not change.

Let us now look at an example to understand the difference between these different types of requirements.

Let us assume that we have a word-processing system that does not have a spell checker. In order to be able to sell the product, it is determined that it must have a spell checker. Hence the business requirement could be stated as: user will be able to correct spelling errors in a document efficiently. Hence, the Spell checker will be included as a feature in the product.

In the next step we need to describe what tasks must be included to accomplish the above-mentioned business requirement. The resulting user requirement could be as follows: finding spelling errors in the document and decide whether to replace each misspelled word with the one chosen from a list of suggested words. It is important to note that this requirement is written from a user’s perspective.

After documenting the user’s perspective in the form of user requirements, the system’s perspective: what is the functionality provided by the system and how will it help the user to accomplish these tasks. Viewed from this angle, the functional requirement for the same user requirement could be written as follows: the spell checker will find and highlight misspelled words. It will then display a dialog box with suggested replacements. The user will be allowed to select from the list of suggested replacements. Upon selection it will replace the misspelled word with the selected word. It will also allow the user to make global replacements.

Finally, a non-functional requirement of the system could require that it must be integrated into the existing word-processor that runs on windows platform.

The official definition for a non-functional requirement specifies how the system should behave:
"A non-functional requirement is a statement of how a system must behave; it is a constraint upon the systems behavior."

Non-functional requirements specify all the remaining requirements not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors, for example: "Display of the patient's vital signs must respond to a change in the patient's status within 2 seconds."

Nonfunctional requirement: In software system engineering, a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.

· Performance - Response Time, Throughput, Utilization, Static Volumetric

· Scalability

· Capacity

· Availability

· Reliability

· Recoverability

· Maintainability

· Serviceability

· Security

· Regulatory

· Manageability

· Environmental

· Data Integrity

· Usability

· Interoperability

2.6 Stakeholders

As mentioned earlier, in order to develop a good requirement document, it is imperative to involve all kinds of user in the requirement engineering process. The first step in fulfillment of this need is the identification of all the stakeholders in the system. Stakeholders are different people who would be interested in the software. It is important to recognize that management carries a lot of weight, but they usually are not the actual users of the system. We need to understand that it is the actual user who will eventually use the system and hence accept or reject the product. Therefore, ignoring the needs of any user class may result in the system failure.

The following diagram shows the role of different stakeholders in the setting the system requirements.

The following figure depicts the relationship between different documents produced during the requirement engineering phase.

3. Use Case Diagrams

A use case is a functionality the users need from the system. A use case diagram depicts the relationships among the actors and use cases.

Generally a single use case is supposed to cover all the actions or events that an actor can perform on the system at one go. The size of use case should not be very large or very small. For example Add User, Manage Profile, View Sales Report, Update Order etc are good medium size use cases. Whereas Enter Password, Display Error Message etc are very small use cases and Manage Sale & Purchase is a very large use case.

3.1. Components:

The components in a use case diagram include:

3.1.1 Actors:

Actors are first thing you need to find for the use case diagram. Actors represent external entities of the system. These can be people or things, such as external hardware that interact with the system.

For example, if an online store is being modeled there can be more than one actor that interacts with the store functionality. Such as the Customer and stocker will be the actors in the system.

It is represented simply by a stick figure with its name at the bottom of it.

3.1.2 Use Cases:

Use cases are functional parts of the system. They figure out what actions/functionalities a user will perform. Use cases are basically the functional requirements that you have pointed out in the functional and non functional requirements topic.

For example: The customer "browses the catalog", "chooses items to buy", and "pays for the items". Here browse catalog, buy item and pay for item are the use cases. Many actors can share a single use cases.

The notation for a use case is an ellipse. As it is displayed below:

3.1.3 Associations:

Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever there is direct interaction between actor and use case. Associations are modeled as lines connecting use cases and actors to one another, with an arrowhead on one end of the line.

3.1.4 System boundary:

System’s boundary is drawn by a rectangle that contains use cases. The actors are placed outside the system boundary and use cases inside it.

3.1.5 Relationship between Use cases

i) Include/Uses:

Include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). <<include>> use cases must be used by the use cases that use them before the latter can be complete. It is displayed in the diagram editor as a dashed line with an open arrow pointing from the base use case to the inclusion use case. The keyword «include» is attached to the connector.

ii) Extend:

A use case extends another use case to do more than the latter. It extends the functionality of one use case to further level. is displayed in the diagram editor as a dashed line with an open arrowhead pointing from the extension use case to the base use case. The arrow is labeled with the keyword «extend».

3.2. Use Case Diagram:

Reference:

http://agile.csc.ncsu.edu/SEMaterials/tutorials/use_case_diagram/

http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.xtools.modeler.doc%2Ftopics%2Fcextend.html

http://blog.casecomplete.com/post/Master-the-Use-Case-Include-Relationship.aspx

4.0 Usage Scenario

Usage scenario is the actual text-based representation of the use case, among various representation methods discussed above. A usage scenario is likely to have various sections depending upon the level of details required in a given system. There is no fixed standard so far for number of sections in a use case (usage scenario).

Following is a typical table structure for usage scenario, note that it is not mandatory to write a usage scenario in the table format only, and it is likely that you will find different structures for the same representation.

Use Case Title	Write Title Here (must match use case title in use case diagram)
Abbreviated Title
Use Case Id
Requirement Id
Description:
Pre Conditions:
Task Sequence		Exceptions
1.
2.
3.
.
.
Post Conditions:
Unresolved issues:
Authority:
Modification history: Author: Description:

Let’s explore each section from the template provided above.

§ Use Case Title

It is the name or label of the use case for which we are writing the usage scenario. Generally it must start with a Verb and it should consist of 2 to 4 words e.g. Add User, Manage User Roles etc.

Use Case Title

Add User

§ Abbreviated Title

Some times we find ourselves in a situation where the use case title is too long. In this case we can use abbreviation in the use case title e.g. using Manage HRM Department in place of Manage Human Resource Management Department. In such cases we should elaborate the abbreviation under the section Abbreviated Title. So we should write: Human Resource Management (HRM) against this section.

Abbreviated Title

Human Resource Management (HRM)

§ Use Case Id

Sometimes use cases are indexed for better reference in overall project documentation/artifacts. This can be any form of series e.g. 1, 2, 3 etc. Priority based use case id is another famous use for this section. Use cases are indexed to present their importance in the system. You would want to set ascending or descending rating or priority for all use cases i.e. the most important use cases are ranked higher so that the project team knows what should be implemented first in the upcoming phases/deliverable of the project.

Use Case Id

§ Requirement Id

The purpose of this section is same as ‘Use Case Id’ section. The number written against this section represents the corresponding functional requirements this use case belongs to. It is compulsory to index all the functional requirements properly before this section can be used:

Requirement Id

§ Description

It should be a very brief description of the use case under discussion. Generally this portion should consist of 2/3 lines.

Description

This use case is about adding a new user to existing system with the privileges defined at time of user account creation.

§ Pre Conditions

This section should enlist what must be true before this use case can be performed.

Pre Conditions:

1. All must-required information about the new user should be available.

2. Database should be available in online mode.

Pre Conditions:

- Administrator is logged in, and there is a need to add a new user account.

§ Task Sequence & Exceptions

This is the most important section of the usage scenario. It is also referred as Success Scenario, Actions, (or simply) Scenario. This should be a list of actor’s interaction with the use case.

Task Sequence	Exceptions
1. Administrator opts to Add a new user account.
2. System asks for necessary information
3. Administrator provides all the required information and opts to complete the operation.
4. System after confirmation adds the new account.
5. System sends the account creation email to the administrator’s email id and user’s email address.
6. A log is saved on the successful operation of the use case.

Another style that is commonly used is as follows:

Task Sequence
User Action	System Response
Administrator opts to Add a new user account.	System asks for necessary information
Administrator provides all the required information and opts to complete the operation.	System after confirmation adds the new account.
	System sends the account creation email to the administrator’s email id and user’s email address.
	A log is saved on the successful operation of the use case.

Some times there are one or more alternate scenarios within a particular usage scenario that must be discussed in order to elaborate the use case properly.

Task Sequence	Exceptions
1. Administrator opts to Add a new user account.
2. System asks for necessary information.
3. Administrator provides all the required information and opts to complete the operation.
4. There is a problem in the data provided; some data needs to be corrected. - Administrator checks the available information and corrects the error. - Administrator continues from the step 3.
5. System after confirmation adds the new account.
6. System sends the account creation email to the administrator’s email id and user’s email address.
7. A log is saved on the successful operation of the use case.

Alternate scenarios could be more than one; in this case, it will be better to make a bold heading to show each alternate scenario separately. Again there can be multiple ways to show the alternate scenarios.

Exceptions are any unhandled scenarios that must be discussed under this section. Some times there are ambiguous situations in start of project that might hurdle the flow of events in the Task Sequence portion. In such situations the details are provided in the Exceptions section. Generally this section should be left blank as in case of final project, you will get fixed requirements at the start and thus there should be no ambiguity.

§ Post Conditions

The conditions that must be true depending upon the successful use case are mentioned in this section.

Post Conditions:

- A new user account is successfully created.

§ Unresolved Issues

In addition to the Exceptions portion, we write unresolved issues (if any) in this section, so that in later phases (when the situation gets more clear).

Just like Exceptions section, this will be generally left blank (or its row can be deleted from the use case table-structure.

§ Authority

The role that is allowed to perform this use case, in our current example it will be Administrator.

§ Modification History

If a use case is updated in later stages of the project development, the versioning information should be mentioned in this section (version can be a series such as 1.0, 2.0, 3.0 or 1.1, 1.2, 1.3 etc)

§ Author

It means the author of this usage scenario. Put your project/group id in this section.

§ Description

Any more details about author, revision of the use case should be provided in this section.

So our final usage scenario is as follows:

Use Case Title	Add User
Use Case Id	1
Requirement Id	3
Description: This use case is about adding a new user to existing system with the privileges defined at time of user account creation.
Pre Conditions: 1. All must-required information about the new user should be available. 2. Database should be available in online mode.
Task Sequence		Exceptions
1. Administrator opts to add a new user account.
2. System asks for necessary information.
3. Administrator provides all the required information and opts to complete the operation.
4. There is a problem in the data provided; some data needs to be corrected. - Administrator checks the available information and corrects the error. - Administrator continues from the step 3.
5. System after confirmation adds the new account.
6. System sends the account creation email to the administrator’s email id and user’s email address.
7. A log is saved on the successful operation of the use case.
Post Conditions: - A new user account is successfully created.
Unresolved issues:
Authority: Administrator
Modification history: 1.0 Author: <Project or Group ID> Description:

§ How to handle <<uses>> (or <<includes>>) and <<extends>> relations:

There might be situations in use case model having some hierarchy, suppose a hierarchy:

Here Process Order is the main use case and Generate Receipt and Process Item Return are its sub-use cases. In this case, just provide the usage scenario for all the sub-use cases as usual, and to refer them inside the usage scenario for main use case, just write ‘User performs Sub-UseCaseNameHere ‘ in the task sequence e.g. in this example, the Task Sequence portion of the use case Process Order will be as follows:

Task Sequence

1. Salesman enters the purchase information in the system.

2. System generates the total amount to be paid by customer.

3. Salesman performs Generate Receipt use case.

4. The customer wants to return some particular items from the order, so step 3 cannot be performed.

- Salesman picks the returned items.

- Salesman performs Process Item Return use case.

- System recalculates and displays the total bill amount.

- Salesman performs step 3 to complete the operation.

Important Points:

ü There should be a usage scenario for each use case from use case diagram e.g. if there are (let say) 10 use cases in use case diagram, then there must be 10 separate usage scenarios (i.e. one for each).

ü Title of use cases in use case diagram and in the usage scenario must be same.

ü As said earlier, there is no standard for any fixed sections in usage scenario, so if you don’t have any thing to write in a particular section, then just leave it blank or delete its row/cell from the table. It is important to note that some sections are very common across different representations of usage scenarios and such sections should not be removed/kept blank at all. These sections are: Use Case Title, Pre Conditions, Post Conditions, Task Sequence, Author etc. Again it all depends upon the situation and level of details required in a given system.

ü Generally a good approach for Task Sequence portion is not to mention very small GUI level details such as:

‘Administrator clicked on Submit button’

‘System shows the confirmation message’

References:

WRITING EFFECTIVE USE CASES (Alistair Cockburn), Addison-Wesley, 2000.

CS& IT Projects

Pages

SRS Phase

1. Project Scope

1.1 What is project scope?