How to Model Software Requirements Effectively | Free UML Guide

Scroll down to access Adaptive's Free UML Guide

From a business analyst’s perspective, the right requirement modeling plays a vital role in letting various stakeholders understand the requirements with ease.

Major styles of requirement modeling currently in practice are as follows – scenario-based model, data or flow model, class model, and behavioral model.

Scenario-based model - This model is prepared from an end-user perspective. Techniques such as use cases, user stories, and activity diagrams would be a major contributor to this model.

Flow-based model – When a requirement deals with a specific data flow that affects various modules of a system, data-based modeling is the best method that can accommodate the system flow and the data flow within the system. This could be a tedious model but it is a helpful model to do impact analysis. Data Flow diagrams, activity diagrams are types of this model.

Class-based model – Class diagrams are the most popular UML diagrams used for the construction of software applications. They are a graphical representation of the static view of the system and represent different aspects of the application. This involves identifying the classes such as the event occurrences, roles, places, structures, and other artifacts involved.

Behavioral model – This modeling happens from a user perspective. Mainly state diagram and sequence diagram builds up this model.

In short, the 5 common types that make up a requirement model are use case, user stories, activity diagram, flow diagram, state diagram, and sequence diagram.

The different modeling technique is individually understandable. However, it is highly important to know how to use these models and when to use them. In some cases, certain models may be more appropriate than the others may, whereas in other cases, almost all the models may be applicable with a difference in weightage. There are 5 major aspects to consider when it comes to deciding on the usage of requirement models. The five aspects are:

• Nature of the requirement
• Type of requirement
• Impact of the requirement in the system
• Users related to the requirement
• The phase of the process that would deal with the requirement

Nature of the requirement – This aspect deals with identifying if a given requirement is an enhancement requirement or a foundation requirement for a new system or a process

Type of requirement – Three major types of requirements that could be considered for deciding the usage of requirements models are a functional requirement, performance requirement, and technical requirement. The functional requirement deals with the operation processes, where the change of state of various parameters would result in the required end-point. Performance requirements are add-ons of an existing process or for a functional requirement, to enhance the process efficiency. Technical requirements can either be allocated requirement that automatically flows from a functional or performance requirement to an element of the system or is a derived requirement that deals with the interfaces between the various stages within a system.

Impact of the requirement in the system – An impact of a requirement in a system could be considered in three different fashions – minimum, medium, and maximum. A minimum impact could be defined as an impact that changes the user experience or the system parameter for a specific instance. An impact would be considered medium if the requirement is indirectly affecting the other related process or system parameters. A maximum impact would be considered where the majority of the parameters of the system or the related processes appear transformed.

Users related to the requirement – Three major types of users would be business users, functional users, and technical users. Business users would have the objective of knowing the business value proposition that would be obtained if the endpoint of the requirement is reached. Functional users would be oriented towards understanding the changes or the impact that could be expected in the direct and indirect process related to the requirement where the technical concern is not a major aspect. Technical users would be aligned towards the development estimation of effort and risk for the given requirement initially and later during the development, they would need the detail related to the nuances to achieve the required endpoint.

Phases of a process – The common phases of a process would be the following- Initial understanding phase, Work estimation & Overall impact analyzing phase, Work initiation, Work in progress, Work in last phase, Quality analysis, End-user acceptance, Delivery.

The judiciousness of choosing the modeling technique depends on choosing the priority of having those five elements of modeling based on the variation in the five aspects of a requirement discussed above.

For each of the modeling types, here’s how the above five aspects are considered:

User Stories: Of the five different types, this style of requirement modeling known as ‘User Stories’ would be easy to understand for any kind of user irrespective of the nature or type of the requirement. User stories are short, concise statements that capture the needs of stakeholders and their expectations out of the system. The impact factor of the requirement may not be considered here because; this model is in the style of one step at a time. User stories would be highly utilized at the time of understanding the requirement, followed by final development testing, quality analysis, and final sign-off. The acceptance criteria of user stories form the guideline for delivery.

Use Case: This technique would be suitable when the requirement is functional in-nature. Use cases depict the high-level functionalities that one would want the system to perform. This technique would be useful to get a foundation level understanding or a holistic style of the requirement.  More than a business user, this would be handy for a functional or technical user. This would play a major role in defining the scope of work, risk, and effort estimation for a given requirement.

Activity diagram – This technique deals with the overall business process or system process – which is suitable for all types of users in line with the nature of requirement being functional and the type being foundational. This technique can aid in impact analysis by just defining the system or process scope but this technique can’t be of assistance for detailed impact analysis.

Flow diagram – This technique is helpful for a specific functional segment of a system or a process. So enhancement requirements of any nature would fit in this technique that would be easy for functional and technical users. After having defined the scope of the system or the process, this flow chart will guide in analyzing the impact in detail. On this front, technical and functional users are the ones who use the flow diagram for their work more than the business users. As a process, the requirement represented as a flow diagram would be highly utilized until the last phase of the development.

State diagram – This technique is more specific compared to a flow chart. Regarding the objects of a system or the process, the various states of an object that happens during a process flow are depicted only in a state diagram. In line with this, only technical and functional users would find this useful especially during the development phase more than the initial and final phases. This element can’t be a direct contributor to the impact analysis parameter.

Sequence diagram – This is more relevant for a technical user, especially when many processes happen in parallel. It provides a visual representation of how processes or objects interact during a scenario. This technique adds more value for technical users, as this will help in drilling down to detailed technical specifications. On the other side, this is the most preferred methodology for requirement reference majorly during the development phase.

Here’s a summary of the above-stated aspects in the form of ‘Requirements modeling techniques’ vs ‘Usage aspects’ matrix -

In a nutshell, business analysts play an instrumental role in modeling needs, requirements, designs, and solutions to facilitate effective analysis and communication and this calls for knowing which techniques to use and when. This article and particularly the matrix provided will act as a guide in understanding the various factors to consider while choosing a requirement modeling technique and understanding which technique applies best in a particular scenario.

Adaptive US UML Training – Model Like a Pro!