Imprestige | Who Comes After Who? Requirements, Use Cases and Features
Languages
Tweets from Imprestige
You currently have access to a subset of Twitter API v2 endpoints and limited v1.1 endpoints (e.g. media post, oauth) only. If you need access to this endpoint, you may need a different access level. You can learn more here: https://developer.twitter.com/en/portal/product

Who Comes After Who? Requirements, Use Cases and Features

2014-10-10
|
IT
  • Who Realizes Who – Featured Image

Realization connectors are great in UML, expressing that one model element represents something at a more concrete or specific level. The element realizing another considers, handles or implements some more abstract concept represented at the higher level of the realized element. To come up with a trivial example, a database table, as a model element, can realize a conceptual class, as well an implementation level class can do. In this example there are two kinds of realizations of the conceptual class: an implementation class conforming to a programming language such as C#, and a table conforming to a given DBMS, such as SQL Server. Realizations, used this way, are effective means of expressing things represent the same concept at different level of details and implementation, and that these elements are closely couple in the sense that a change in the realized element may imply changes in those realizing it. Realization flows express how things become more and more specific as the modeling/designing process forwards.

People, however, get a little bit confused when it comes to realization connectors between use cases and requirements, according to conversations conducted with analysts.

The basic question is whether a use case realizes a requirement or a requirement realizes a use case. Finding the correct answer is impacted by many more or less correct examples found on the net, as well as by the examples incorporated in the help of CASE tools. Sparx Systems in Enterprise Architect documentation, for example, only mentions the case of a requirement realizing a use case. While it is one of the options and is syntactically correct, it is not necessarily the only viable approach: just do not forget, Sparx developers and document writers are not necessary the most experienced people in UML, and their goal is not to teach you UML. They only gave an example.

Okay, to answer the issue, look at the concepts involved, since improper definition is causing the confusion. Let’s start with use cases: they are part of the UML specification, their definition is therefore clear (but is put in simpler words for now):

  • A use case is a high-level capture of some part of the externally visible behaviour of a planned software in terms of interactions conducted with actors.

Requirements (requirement elements) are, however, not part of the UML standard, but are defined in a UML extension, just as features (feature) elements are. That means the author of the extension defines, evidently, what an extension element is used for and how to interpret it.

The Sparx Way

To put it simple, Sparx’s definitions say:

  • A requirement is something (a rule, statement, behavior etc.) a software must meet.
  • A feature is (a piece of) something (screen, function, behavioral element etc.) a software must have.

According to these definitions, EA examples stimulate you can have some simple high-level requirements just as the necessity of displaying reports. In this approach, you then define use cases to illustrate how external parties interact with the system to satisfy the requirement. Then, as the last step of analysis, you define those features the software will have to satisfy all these requirements, interactions and conditions. The relations are shown in the figure, with the requirements shown in green and features in blue boxes.

Using requirements, use cases and features as suggested by Sparx Enterprise Architect help

Using requirements, use cases and features as suggested by Sparx Enterprise Architect help (click to zoom)

According to EA documentation, features are fine-grained elements expressed in client-valued terms which define the means of interactions specified by the use cases. Basically the connection between use cases and features (the blue boxes) is said to follow the concepts of Feature-Driven Development methodology, but the methodology does not actually incorporate the concept of requirements, nor that of use cases, so mixing them is out of the scope of the original methodology.

Interpreting the Example

In this approach we start with requirements, which are high-level descriptions of what a system should be capable of.

  1. Requirement RQ1 says the system shall be able to display and export business reports.
  2. Use case UC1 defines the interaction behavior of how the system is expected to conduct the activity of displaying reports. (Basic steps are on the note element.) This use case is said to realize the requirement of displaying and exporting business reports.
  3. At the last analysis step, feature elements are defined to clarify and detail what functions and other characteristics the software will have to support the use case.

The Conventional Way Around

There is another way though in using these model artifacts, which I’d call a bit more conventional. This is based on separating the analysis phase of the development cycle into three phases. The visioning phase is to gather business or high-level requirements called features (just as most important functions of a software are called features in product pages). The features tell the analyst what kind of behaviors to find or develop at the use-case level. When use cases are defined, during the use case modeling phase or usage analysis phase, the requirements to enable the correct implementation of the use cases should be specified at a much more detailed, sometimes more technical level. This latter is called the requirements specification phase. See the following figure.

Using requirements, use cases and features as suggested by the conventional way

Using requirements, use cases and features as suggested by the conventional way (click to zoom)

This paradigm defines the terms as follows:

  • A feature is a high-level description by the business actors of what a software should have, perform, offer or feature. The set of features is called vision.
  • A requirement is a piece of information concerning the functionality, ergonomics, conformance, performance or other aspect of a software, including business rules, which shall be met by the software and which is detailed enough to estimate the related efforts—and the requirements model is detailed enough when it is broken down into work assets or tasks.

Interpreting the Example

In this approach we first create features:

  1. Clients tell what features they would like to see in the system, such as displaying and exporting reports.
  2. Then a use case is defined to describe the interaction pattern supporting this goal.
  3. Finally requirements are created to clarify and detail what kinds of requirements shall be set against the system to make sure the use case will be properly supported.

Which Out Of the Two?

The No. 1 rule of thumb in modeling is all elements shall be interpreted according to their definition. If you happen to draw little clouds to incorporate use cases and you define the cloud symbol as a representation of use cases in your documents, you are fine, and your reader should be able to correctly interpret you. There are, however, lots of conventions which gained popularity in the industry and which people will think they know. Putting requirements into ellipses what use cases are represented by in UML would not be a good choice, no matter if you clearly define it: people experienced in UML will see them as use cases because that is a standard notation, and they will not assume you gave it another meaning.

But nor requirements, neither features are defined in UML, so it’s practically up to you how you use them. It’s pretty sure both approaches can be employed successfully, and both can fail in lack of expertise, clear definition of the meta-model and consistent use.

Personally I prefer the conventional way for the following reasons:

  • The presence of realizations: The Sparx way connects use cases and requirements with realization connectors, meaning a use case realizes a requirement. In my mind use cases are the primary goals a system shall achieve or support, top-level in this sense, and they are the items what should dictate requirements, not vice versa. On the other hand, if you’d happen to find your requirement needs two use cases, you can not properly model this situation: realization connections are complete, not partial. If you have Q and R realizing P, it means Q and R gives two different realizations of P, rather than realizing or implementing P together. So in the Sparx way you can only have one use case for each requirement, which is an unnecessarily strong limitation.
  • Connector directions: In the EA way your connectors will all be directed away from the use cases: realization arrow shall be located at the realized element (the requirement, in this case), and trace arrows (defining change/impact paths) should be located at the more detailed or potentially impacted element. Most of your clients, however, will find a sequence of arrows pointing to one direction more straightforward. They will more easily accept the second diagram, where the flow of connectors more clearly shows the way ahead.
  • The term “feature”: When talking to business actors, it is dangerous to play with the term requirement: often they will flood you with implementation details they have visioned, instead of focusing on real requirements. They will tell you about the specifics of an Excel sheet, instead of clearly telling you what data and functions they expect in a report, giving no chance to clearly understood requirements and to come up with some more effective, cheaper, faster or otherwise better solution. When you talk about business goals and features, they are most likely to tell you the correct things: what the software should be able to perform or offer.
  • The term “requirement”: Not only functional requirements exist. Though often overlooked, there are requirements concerning security, ergonomics, regulatory environment, performance and so on. In the Sparx way, you should either call them features, or keep them at high-level, none of which being my taste. To reach a more balanced state, elements of the same type should basically define the same level and similarly specific information. Plus the phrase requirement is a more significant term to express something shall be met or satisfied, and people will take them more seriously.

(Cover photo by Svilen Milev)

About

Professional with a vision
Gusztáv, the founder and manager of Imprestige Ltd. is an experienced Business Analyst, IT Consultant, Quality Assurance Specialist and Professional Translator, sharing his time between IT projects and translation/localization projects.

Committed to professionalism and quality, in his IT roles he is an evangelist of well-organized software development ensuring agility, productivity and outstanding ROI during the application lifecycle. He is also passionate for creating great user experiences and highly intuitive solutions.

As a translator, Gusztáv belongs to those stimulating and pioneering the creation of clearly speaking translations, realizing that intelligibility and concise phrasing is inevitable in order to enable vendors to exploit the values embedded in their solutions.

For a detailed resume and reference information, please visit: http://gusztav.janvari.name