How to Gather Requirements and Create Use Cases

Gathering Requirements 

Requirement gathering is a very significant stage of a project and the entire project management since it helps in understanding the process and possible outcome. Most projects kick off without gathering requirements only to end up failing to meet the customers’ expectations and consequently customers’ dissatisfaction ( De Landtsheer, Ospina, Massonet, Schmitt & Jeschke 2017). Basically, there are two requirements techniques used to deliver effective and successful projects which are the non-functional requirements and the functional requirements. 

Non-functional requirements 

The non-functional requirements describe the visual properties of the system used and the performance expected in a project ( Laplante, 2017). The intended environment for the end product, its portability, durability and eventually the security measures put in place for the product. 

Functional requirements 

The functional requirements major on the description of the product’s functionality, the scope of the system used, and the set boundaries to the immediate systems ( Laplante, 2017). In addition, the functional requirements outline the business rules required for the system to conform to depending on the nature of the business. 

However, for a requirement to be effective and viable it should be verifiable upon implementation and must prioritize on the first part of a project to be implemented. In addition, a requirement should be complete to the desired criteria, should be clear to avoid misinterpretation of the clients, and should have only the parts required for the project ( De Landtsheer, Ospina, Massonet, Schmitt & Jeschke 2017). Lastly, a system should invest in experts who have the know-how on the existing processes and programs. 

Creating Use Cases 

Use cases help in the integration of requirements into an all-inclusive platform that allows for the interaction of users within the system. Also, the use cases describe the relationship between the actor, their roles, and the systems ( Fitzhenry, Resnic, Robbins, Denton, Nookala, Meeker & Matheny, 2015). The actor is a different hardware used outside the system, often not aware of the activities of the system. Therefore, the use cases help in eliminating a possibility of an existing misunderstanding all along the system functionality. 

References 

De Landtsheer, R., Ospina, G., Massonet, P., Schmitt, R., & Jeschke, S. (2017, October). Requirements Gathering and Validation for Risk-Oriented Tool Support in Supply Chains. In  Simulation and Modeling Methodologies, Technologies and Applications: International Conference, SIMULTECH 2016 Lisbon, Portugal, July 29-31, 2016, Revised Selected Papers (Vol. 676, p. 120). Springer. 

Fitzhenry, F., Resnic, F. S., Robbins, S. L., Denton, J., Nookala, L., Meeker, D., & Matheny, M. E. (2015). Creating a common data model for comparative effectiveness with the observational medical outcomes partnership.  Applied clinical informatics ,  6 (03), 536- 547. 

Laplante, P. A. (2017).  Requirements engineering for software and systems . Auerbach Publications.