Cost of living by country Travel cost by country Salary of professionals by country Salary of politicians by country Lotteries by country Tutorials menu

Example of a requirement for use cases for a new process


Example of a requirement for use cases for a new process

Software Engineering->Analysis, design and implementation of software->Example of a requirement for use cases for a new process

Share on


¿How should socialization with the client be with use cases?

Socialization with the client to determine the use cases that should be documented in the requirements survey should focus on the following points:

* Define the organizations process to identify the points where the information system will support the users tasks.
* Customers need, SEO or problem.
* Business rules.
* Data.
* Flow of events.

Where the initial role that the requirements-setting analyst must exercise is to explain to the client the five points mentioned and later take the role of listening and writing down everything that the client is informing to later begin to ask questions that allow to break down the need of the client at a level of detail that allows them to understand and draw up a requirement document with the highest possible quality% for subsequent technical analysis.

The survey of requirements by processes is the best alternative to document the clients need in the scenario where the business income is going to be obtained from the provision of linked services within the information system.

Being the information system to implement the core of the business, it is advisable to define and document the organizations processes initially and later identify the points of the process where the information system will support the users tasks, thus achieving an information system that it adapts correctly to the process flows and reduce training costs because the information system is adapted to the way the business works.



¿How should the use cases document be?

Once the process flows are documented, the requirements survey analyst will take the process flows and in the company of the client they will identify the points where the information system must support the tasks of the users, thus understanding the clients need and proceed. with the following documentation for functionality.

1) Business rules: Define the validations that the software must perform within the process flow.

2) Non-functional requirements: Define the characteristics that each software functionality that will be part of the process flow must have with respect to performance, usability, load, among others.

3) Data dictionary: Define the Characteristics of the data that users want to operate within the process flow.

4) Flow of events: Define the operation steps that the users and the system must perform to achieve the expected result and include the exceptions, that is, when the system or the user cannot complete a step successfully.

The defined operation steps must not be outside the process flow.



¿How to avoid errors in the lifting of requirements?

The most frequent errors during the raising of requirements by processes are the following:

1) Not understanding what the client communicates: It is very frequent that the analyst who gathers requirements in time periods during the socialization with the client dissipates his attention and begins to assume things leading to the creation of a document of requirements with information gaps which will impact the technical analysis, therefore, the requirements-setter analyst must always be with all 5 senses placed in socialization and ask everything that does not understand so the expected answer is very obvious.

2) Not having studied the clients business model: You cannot be an expert in everything. However, if it is possible that before scheduling the socialization with the client, the requirements-setting analyst carries out a general investigation of how the clients business model behaves so that when the socialization is carried out, he can establish a more fluid communication and finally manage to raise a requirement document with the highest possible quality.

3) Not having the business process flows. It is common that the client when requesting an information system tailored to their business does not have the organizations process flows, therefore, The probability of omitting information in the software requirement document is increased, either because the client is not clear about how they want the software to operate or because the requirements analyst did not ask the correct questions during the socialization with the client. recommends that before beginning the requirements survey, the organizations process flows be built, thus achieving that the client identifies how they want the tailored information system to be correctly adapted to the business operation.

Below is an example of a requirement survey for use cases for a new process which can be used and adapted in your projects.



Created by - Being its last update the: 2021-10-22

Download template

X

Send template

Enter the email address where you want to send the template and press the (Send) button

Send comment

X

Send comment

Other topics of interest