Use Case Based Requirement Elicitation

Published Date: 02 Nov 2017

Abstract

Requirements engineering is not straightforward for any software development team. To establish and manage a good set of requirements is one of the critical success factors for any system project, and for the development of any complex product in general. Developing software when team members are located in widely distributed geographic locations poses many challenges for developers, particularly during the requirements engineering phase.

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

1 Introduction

"Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families."

Requirements engineering (RE) is an important phase in the development of information systems. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting them in a form that is amenable to analysis, communication, and subsequent implementation.

Requirements Engineering (RE) research has played a critical part in systems development through exploring, studying and addressing issues of concern to both developer and business communities.

There are a number of difficulties in this process. Stakeholders may be numerous and distributed. Their goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish.In this paper we present an overview of current research in RE, presented in terms of the main activities that constitute this field. While these activities are described independently and in a particular order, in practice, they are actually

interleaved, iterative, and may span the entire software systems development life cycle.

In the process, there are some areas that can be used to categories and

compare RE activities; they include:

• Requirements Elicitation

· Requirement Analysis

· Requirement Specification

· Requirements Validation

Requirements engineering is a process that continues through the lifetime of a system as the requirements are subject to change and new requirements must be elicited and documented and existing requirements managed over the lifetime of the system.

http://t0.gstatic.com/images?q=tbn:ANd9GcThqaxpPBXSPRglBObCM3rGXW5gp0pBNDmyHRrPp0lzUZRZLIhv&t=1

2 Requirement Elicitations

Requirement Elicitation is the first step for requirement engineering process. It is an effective procedure for gathering the exact requirements from the customer’s site through various advance methods:

2.1 Brainstorming

Brainstorming is a group oriented approach to extract the requirements from the customer. An effective session is conducted and every participants are free to expose their ideas in these ideas will be documented in such a way that everyone can see it. After a completion of session a detailed report is prepared and finally a document will be prepared which have list of requirements and their priorities.

2.2 Facilitated Application Specification Technique (FAST)

In FAST, a team of customers and developers work together to identify the problem and corresponding solution. Similar to the Brainstorming a meeting is organized at neutral site and controlled by a facilitator. Before the meeting a list of object is prepared and after the discussion some of the entries from the list is eliminated and new entries are also added to the list.

2.3 Quality Function Deployment

In this method, technical requirements are documented and three types of requirements are also identified:

2.3.1 Normal Requirement: The main functional requirement of the software product are identified.

2.3.2 Expected Requirement: Expected Requirements do not state explicitly by the customer and it enhance the level of satisfaction.

For ex- Protection from unauthorized access.

2.3.3. Exciting Requirement: These are beyond the customer expectation and make more satisfy to the customer.

For Ex- Providing an additional copy of important files of the software.

2.4 Delphi Technique

In Delphi technique session all the participants make a note of their requirement and exchanged them with each other. This process is repeated till all the participant agree on a common set of requirements.

2.5 Use Case Based Requirement Elicitation

Use case approach uses a combination of text and pictures. In order to improve the understanding of requirement. The two component, actor and use case, are used for design of use case approach. An actor can be a person, machine or a Information System that is external to the system model. Use Case describe the sequence of interaction between actor and the system necessary to deliver the services that satisfies the goal.

3 Requirement Analysis

The purpose of System Requirements Analysis is to obtain a thorough and detailed understanding of the business need as defined in Project Origination and captured in the Business

Case, and to break it down into discrete requirements, which are then clearly defined, reviewed and agreed upon with the Customer Decision-Makers. During System Requirements Analysis, the framework for the application is developed, providing the foundation for all future design and development efforts.

http://upload.wikimedia.org/wikipedia/commons/thumb/a/a1/SE_Process.jpg/320px-SE_Process.jpg

Types of Requirements: Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:

Customer Requirements: Statements of fact and assumptions that define the expectations of the

system in terms of mission objectives, environment, constraints, and measures of effectiveness

and suitability (MOE/MOS). The customers are those that perform the eight primary functions of

systems engineering, with special emphasis on the operator as the key customer.

Operational requirements will define the basic need and, at a minimum, answer the questions posed in Figure 4-1.

Functional Requirements: The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the toplevel functions for functional analysis.

Performance Requirements: The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

Design Requirements: The "build to," "code to," and "buy to" requirements for products and "how to execute" requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements: Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements: A requirement that is established by dividing or otherwise allocating a

high-level requirement into multiple lower-level requirements. Example: A 100-pound item that

consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

4 Requirement Specification

An abstract description of the software that serves as a basis for detailed design and implementation.

Types of Requirements:

Functional requirements,

Performance requirements,

Interface requirements,

Operational requirements,

Resource requirements,

Verification requirements,

Acceptance testing requirements,

Documentation requirements,

Quality requirements,

Safety requirements,

Reliability requirements and

Maintainability requirements

Functional Requirements: Functional or behavioral requirements are a sub-set of the overall system requirements. These requirements are used to consider trade-offs, system behavior, redundancy and human aspects. Trade-offs may be between hardware and software issues, weighing up the benefits of each. Behavioral requirements, as well as describing how the system will operate under normal operation should also consider the consequences and response due to software failure or invalid inputs to the system.

Performance Requirements: All performance requirements must have a value which is measurable and quantitative, not a value which is perceptive.

Performance requirements are stated in measurable values, such as rate, frequency, speeds and levels. The values specified must also be in some recognized unit, for example meters, centimeter square, BAR, kilometers per hour, etc. The performance values are based either on values extracted from the system specification, or on an estimated value.

Interface Requirements: Interface requirements, at this stage are handled separately, with hardware requirements being derived separately from the software requirements. Software interfaces include dealing with an existing software system, or any interface standard that has been requested. Hardware requirements, unlike software give room for trade-offs if they are not fully defined, however all assumptions should be defined and carefully documented.

Operational Requirements: Operational requirements give an "in the field" view to the specification, detailing such things as:

how the system will operate,

what is the operator syntax,

how the system will communicate with the operators,

how many operators are required and their qualification,

what tasks will each operator be required to perform,

what assistance/help is provided by the system,

any error messages and how they are displayed, and

what the screen layout looks like.

Resource Requirements: Resource requirements divulge the design constraints relating to the utilisation of the system hardware. Software restrictions may be placed on only using specific, certified, standard compilers and databases. Hardware restrictions include amount, percentage or mean use of the available memory and the amount of memory available. The definition of available hardware is specially important when the extension of the hardware, late in the development life cycle is impossible or expensive.

Verification Requirements: Verification requirements take into account how customer acceptance will be conducted at the completion of the project. Here a reference should be made to the verification plan document. Verification requirements specify how the functional and the performance requirements are to be measured and verified. The measurements taken may include

simulation, emulation and live tests with real or simulated inputs. The requirements should also state whether the measurement tests are to be staged or completed on conclusion of the project, and whether a representative from the client’s company should be present.

Acceptance Testing Requirements: Acceptance test requirements detail the types of tests which are to be performed prior to customer acceptance. These tests should be formalized in an acceptance test document.

Documentation Requirements: Documentation requirements specify what documentation is to be supplied to the client, either through or at the end of the project. The documentation supplied to the client may include project specific documentation as well as user guides and any other relevant documentation.

Quality Requirements: Quality requirements will specify any international as well as local standards which should be adhered to. The quality requirements should be addressed in the quality assurance plan, which is a core part of the quality assurance document.

Safety Requirements: Safety requirements cover not only human safety, but also equipment and data safety. Human safety considerations include protecting the operator from moving parts, electrical circuitry and other physical dangers. There may be special operating procedures, which if ignored my lead to a hazardous or dangerous condition occurring. Equipment safety includes safeguarding the software system from unauthorized access either electronically or physically. An example of a safety requirement may be that a monitor used in the system will conform to certain screen emission standards or that the system will be installed in a Faraday Cage with a combination door lock.

Reliability Requirements: Reliability requirements are those which the software must meet in order to perform a specific function under certain stated conditions, for a given period of time. The level of reliability requirement can be dependant on the type of system, i.e. the more critical or life threatening the system, the higher the level of reliability required. Reliability can be measured in a number of ways including number of bugs per x lines of code, mean time to failure and as a percentage of the time the system will be operational before crashing or an error occurring.

Maintainability Requirements: Maintainability requirements look at the long term lift of the proposed system. Requirements should take into consideration any expected changes in the software system, any changes of the computer hardware configuration and special consideration should be given to software operating at sites where software support is not available.

Requirement Validation:

It ensures that the software being developed (or changed) will satisfy its stakeholders 

253.png (1839×1156)