The Use Case Technique: Mapping effective interaction with the system

In systems engineering, use cases are used at an advanced level than within software engineering, often demonstrating missions or stakeholder goals. The comprehensive requirements may then be captured in Systems Modelling Language or as predetermined statements.

Business analyst should try to extract requirements through use cases. A method should be defined to capture user requirements.Use cases originated from object-oriented world, which applies to general requirements analysis. BA’s should ask stakeholders questions focusing on actual, but abstracted, usage scenarios. The questions should be like “Describe a goal you wish to accomplish with the system” and not “What do you expect the system to do.?” The arrangement of actor’s actions and the response of the system should be written properly which would help in deriving functional requirement and enable to create a tests from the use cases.

There are three levels of software requirement that are used to map different echelons of stakeholder, user and actual functional requirement of the system.

Business Requirement:

Business requirements are what must be delivered to provide values. Products, systems, software, and processes are the ways how to provide, satisfy, or meet the business requirements. Requirements such as benefits of the product,different business rules, HR policies, local policies and security policy which are captured in the vision and scope document helping in resolving the ‘why’ questions by the business and the stakeholders.

Confusion arises for three main reasons.

1. A common practice is to refer to objectives, or expected benefits, as 'business requirements.' 
2. People commonly use the term 'requirements' to pertain to the features of the product, system, software expected to be created.
3. A widely held model says these two types of requirements differ only in level of detail or abstraction—wherein 'business requirements' are high-level and vague and decompose into product, system, or software requirements that are detailed.

Such confusion can be avoided by recognizing that business requirements are not objectives but rather meet objectives when satisfied.

User Requirement:

The user requirement specification is a document which is usually used in software engineering that states what the user expects the software to be able to do.Business analyst need to emphasize more on the business rules and quality attribute (scalability, maintainability, performance) the system should display to the user. This document explains what the users want to do or what they want to accomplish with the system.

Once the required information is completely gathered it is documented in a user requirement specification, which is meant to spell out exactly what the software must do and it becomes part of the predetermined agreement. A customer cannot demand features that are not specified in the user requirement specification, whilst the developer cannot claim the product is ready if it does not meet afeature of the user requirement specification.

Functional Requirement:

In software engineering, a functional requirement sketches the function of the system and its machineries. A function is described as a set of inputs, itsbehaviour, and outputs. BA’s needs to putconcise efforts on the having detailed calculations on technical details, data manipulation and processing and other explicit functionality that define what a system is supposed to accomplish.

Behavioral requirements should also be captured concisely in the use case describing all the cases where the system uses the functional requirements.

Functional requirements are braced by non-functional requirements (also recognized as quality requirements), which enforce limitations on the design or implementation (such as performance, localization, data migration, security and reliability).

Commonly, functional requirements are expressed in the form "system must do", while non-functional requirements are "system shall be". The strategy for implementing functional requirements are mapped in the system design. The strategy for implementing non-functional requirements are mapped in the system architecture.

Benefits from the Use Case Approach:

Use cases are user and task centric approach of implementing the users’ terminology and what the user expects from the system. It helps the BA’s in understanding specific application domain also helps in avoiding building unnecessary functionality that is not required by the stakeholders. It permits early drafting of functional tests and sets implementation priorities on functional requirements.

Appropriate Use Case Applications:

Use cases may or may not work well for each and every project implementation. Below are some of the application for which use case are necessary:

• End-user applications: Banking application, MIS system, different management system etc.
• Web sites: Shopping sites, Internet Banking etc.
• Devices with which users must interact: Android, iOS and Windows mobile applications.

Some of the applications or process for which use case isn’t of much importance:

• Batch processes: Print2Flash.
• Computationally-intensive systems: Operating system.
• Event-driven real-time systems:Real-time Electricity Market.

Two schools of thought:

• Use cases are the functional requirements.
• Use cases disclose the functional requirements

It is very important for Business analysts to map actual requirement to the specified documents. It will help to implement all the business, user and functional requirement while adhering to the agile process. They are also responsible for asking precise questions to the stakeholder and map it into the document and not develop a system that does not meet the end users’ requirements.

About the author:

Varun Shimoga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: varun.shimoga@spluspl.com