Software Engineering Assignment

Software Requirements Elicitation

Requirements specify a set of functions a software development project must deliver. Functional requirements define system capabilities, for example, “The system shall permit users to inquire about Berta’s Pizzeria menu via an email message.” Additionally requirements specify non-functional standards that the system must operate within. Examples of non-functional requirements are performance, quality, safety, security, and interface requirements. An example of a performance requirement is, “The system shall have the ability to process 1MB/sec of input.” An example of a quality requirement is, “The MTBF (mean time between failures) shall be greater than 90 days.”

The iterative and incremental development processes of agile methods permit frequent changes to requirements and documentation. Early requirements analysis is required only for features developed in early iterations. Scrum and XP are agile methods that facilitate requirements gathering flexibility. Agile methods require direct involvement of the end-user though-out the software lifecycle. The requirement elicitation differs depending on the agile methodology used. The Unified Process (UP) creates use cases as requirements. Scrum records initial requirements in the form of a product backlog and prioritises them. Extreme Programming (XP) derives user stories and organizes them on a corkboard, or storyboard into deliverables for each iteration.

Requirements elicitation is considered the most difficult part of a development project. The Importance of identifying correct requirements is valuable to the both software developer and the customer. Systems delivered according to incorrect or inadequate requirements may be disparaging to the development organization and disappointing and wasteful to the client. Difficulties with requirements elicitation and analysis include:

1. lack of domain knowledge by the development team

2. Users are not knowledgeable of software capabilities

3. A communication disconnect between the users and the development team

4. Stakeholders cannot definitively specify the requirements

5. Stakeholders underestimate the importance of requirements gathering

6. Nonfunctional requirements are not addressed

7. Stakeholders alter the requirements during the software lifecycle

Requirements elicitation steps include:

1. collection of application information

2. optionally building analysis models

3. developing requirements and constraints

4. feasibility study

5. requirements specification review

The collection of application information involves inquiries about internal and external influences on the business environment, policies, regulations, business goals, and standards. Analysis models may be constructed to understand the business processes and objectives. The customer or user plays a critical role in driving and prioritizing requirements to satisfy the business needs. When the practicability of implementing particular requirements is in question, a feasibility study may take place to assess the risks associated with implementing the requirements. Afterward, a requirements review by all stakeholders, customers, users, domain experts, and developers occurs. For the Unified process (UP), use cases are then derived.

Agile development avoids passing extended lengths of time gathering requirements. Requirements gathering for agile develop deconstructs large projects into the highest priority requirements and addresses an adequate amount of high priority requirements in separate iterations. Stakeholders develop a list of high priority requirements that are expected to change during succeeding iterations. Agile requirements elicitation adheres to the following principles

1. Customer participation and active end-user involvement are essential

2. Stakeholders gather requirements at a high-level and defer details to future iterations

3. Stakeholders quickly produce a software requirements list and go to the next step

4. If needed, stakeholders quickly build models for analysis during requirements elicitation

Deriving Use Cases From Requirements

When developing software using the Unified Process (UP) stakeholders derive use cases from requirements. A use case provides interaction details about an actor interacting with a software application to accomplish a business task.

Use cases have four essential attributes.

1. A use case describes a functional process

2. An actor initiates a use case

3. An actor ends a use case

4. A use case must model an operational undertaking of the actor

There are five steps to derive use cases from requirements.

1. Identify use cases

   1. Identify use cases by reviewing the requirements and searching for verb-noun phrases, such as register customer, respond email, or order pizza. These verb-noun phrases suggest business processes.

   2. Additionally, actors may be derived from noun phrases. For example, from the verb-noun phrase, register customer, the actor, customer, could be derived.

   3. Stakeholders can derive subsystems from the verb-noun phrases. Stakeholders might derive a website subsystem from the verb-noun phrase, authenticate website visitor. Organize use cases by the subsystem.

   4. Create a traceability matrix. A traceability matrix shows how stakeholder map each use case back to a requirement.

2. Specify use case scope

The scope of a use case, where it begins and where it ends, is specified in a high-level use case. A stakeholder must specify three (3) pieces of information for each use case.

1. The action by the actor that starts the use case

2. Where the action by the actor occurs

3. The action the actor performs to signify an end to the use case.

Use cases should contain two declarative sentences that start and end the use cases.

1. The first sentence is patterned as follows, “This use case begins when (TUCBW),” the actor performs an action and where the actor performs the action.

2. The second sentence is patterned as follows, “This uses case ends when (TUCEW),” the actor acknowledges that the business objective of the use case was fulfilled. The actor’s acknowledgment could be implicit or explicit.

Example:

Specify high-level use cases for login into a website

UC1. Login a website

1. TUCBW a visitor browses to the Berta’s Pizzeria website login page.

2. TUCEW the visitor sees the website’s main page

3. Visualize use case contexts

Textual use cases are not appropriate for large systems, UML use case diagrams are suitable to depict use cases for systems with many actors and subsystems.

A use case diagram is described below.

1. A behavioral UML diagram

2. Shows actors that interact with the system

3. Shows the boundaries of the system or subsystem

4. Shows inheritance between actors

5. Shows relationships between use cases

Table 1 Use case notation

Figure 7 Use case diagram that shows actor inheritance

1. Review the use cases and diagrams

The abstract or high level use cases and use case diagrams are reviewed.

1. Assign use cases to iterations

The use cases are prioritized according to the requirements’ priorities. Now iterations are planed using use cases. Three (3) factors should be taken into account when planning the schedule.

1. Use case priorities

2. Dependencies between use cases

3. The effort required to implement the use cases