Will User Stories be able to Handle Non Functional Requirements ?

Let's say that you are a responsible for writing requirements and your project will start using User Stories (US) as a preferred method for gathering requirements. Cool, that's awesome. There are many advantages of using user stories instead of the old Use Case (from RUP) and others methodologies. However (there is always a however) you start to get stuck writing Non Functional Requirements (NFR) and then when you see it, you already lost a precious time in this part. What should you do?

Assumption 1: We already know that a US is generally written as Card, Conversation and Confirmation (called also as Definition of Done).

Assumption 2: We also understand that a good US should be INVEST. Independent, Negotiable, Valuable, Estimable, Small, Testable.

Without any further due, let's start with a simple example of how to write an NFR into a US.

Example 1 as NFR

ID: NFR0024 (Most of the companies use a notation near to that)

Name: Compatibility with Windows and Linux operating systems

Description: The system must be able to run on Linux and Windows operating systems. For Linux the variant used is Ubuntu from version 15.10 (to 17.04), for Windows from version 7 (to 10), always considering the latest service pack. For both systems, manufacturer updates are rigorously applied whenever they are released. The system, because it is a desktop application in client/server architecture, should run on the operating systems listed in this requirement considering the other information described here. The behaviour should be the same, both in terms of functionality and installation.

Note: for this requirement, there will be a guarantee from the system vendor that the application releases will maintain backwards compatibility with the above-mentioned operating systems. This warranty shall remain in force for as long as the maintenance contract is in force.

Example 1 as US

Card: As a user of the system, I want to be able to run your product on all versions of Windows from Windows 7 and on and Ubuntu 15.10 and on, so that I can have the same software on all company's computer.

Conversation and Confirmation: In here you can specify that you also should be able to install the software, and should be able to apply updates and patches. You could also add that the system should maintain backwards compatibility and other more small details.

This example was just a warm up... I wish that all my NFRs were easy like that... Now let's see how you can handle a more complex one...

Example 2 as NFR

ID: NFR0304

Name: Architectural division of the layered system for decoupling

Description: The design of the software should be strongly oriented to low coupling and high cohesion, emphasising the best separation of responsibilities.

The entire project should be done using a separate layered architecture, where each layer will contain only the algorithms related to its responsibility. Below the layers that should be used, and their responsibilities:

• Interface: host screen logics, field validation, triggering commands, codes for interface design etc. Note: For this layer, the "code behind" of each screen must be used, and an "additional" layer can not be created.
• Business: to house business logic, where it will be codified the scope of the business rules associated with the functional requirements pertinent to the functionality.
• Data: to host data access logics, SQL commands or commands to use persistence mechanisms used, in the case of ORM (Object-Relational Mapping) use.
• Security: to host logics of authentication, auditing, maintenance of users.
• Infrastructure: to host logics not related to graphical interfaces, business rules, data or security, but which can be used in all these layers. It will contain resources for recording logs, file transfers, messages, sending/receiving emails etc.

Note: in any of the layers will be allowed methods with more than 40 lines of code.

That's what I'm talking about... But for some reason I find this NFR a little bit tricky, do you know why?

I never saw a stakeholder asking a Product Owner for a system that is "High Cohesion and Loose Coupling". Most of the times, stakeholders will care only about performance, security, usability and even compatibility when we consider NFRs, but never about Architectural decisions, most of the time the development team will be the one doing these calls during the sprint. The only case that I can think of is if your company has a specific team for defining the architecture of your software, but the I believe the architect should be even considered as part of the development team. However that is another discussion, let's come back to our Example 2.

I must confess that I tend to write the requirement using the main syntax of US. Why so? On my understanding, the beauty of this approach is that all requirements look the same, can be understood by everyone including non-technical folk, and therefore has the same visibility as other stories.

Example 2 as US

Card: As an IT Department user, I want a high cohesion and loose coupling software, so that can operate independently of each other with no problems.

Conversation: The entire project should be done using a separate layered architecture, where each layer will contain only the algorithms related to its responsibility. The defined layers for this software are: interface; business; data; security; infrastructure. Below the layers that should be used, and their responsibilities: Interface: host screen logics, field validation, triggering commands, codes for interface design etc. Note: For this layer, the "code behind" of each screen must be used, and an "additional" layer can not be created. Business: to house business logic, where it will be codified the scope of the business rules associated with the functional requirements pertinent to the functionality. Data: to host data access logics, SQL commands or commands to use persistence mechanisms used, in the case of ORM (Object-Relational Mapping) use. Security: to host logics of authentication, auditing, maintenance of users. Infrastructure: to host logics not related to graphical interfaces, business rules, data or security, but which can be used in all these layers. It will contain resources for recording logs, file transfers, messages, sending/receiving emails etc.

Confirmation: 1) Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds.

2) Verify that in a case that Module A goes down, the other Modules (B, C, ...) will still be able to work independently.

3) Verify that all "select", "insert", "delete", "update" (CRUD) commands will be hosted on Data layer.

4) Verify that the rate Module Coupling is not greater than 0.8 (You can see the formula in here).

5) Verify that requests over Internet should use HTTPS protocol and parameters be safely passed in URLs.

6) Verify that user won't have direct access to query on Database.

7) Verify that the system should be able to audit requests for the last 4 months.

8) Verify that all field validations are inserted on interface layer.

9) Verify that all Business Rules will be implemented on Business layer.

10) Verify that in any of the layers will be allowed methods with more than 40 lines of code.

11) etc. (I could have written more dozen of Confirmations, but you got the whole point)

Summary of Example 2

As you saw, my card wasn't that brilliant and innovative, but I rather putting my chips on the Conversation and Confirmation, by doing so, we still can put a lot of granularity in a US and have it simply by someone that will just take a look at the Card.

Why I'd choose IT Department user on my Card? Because at the end of the day when you have a system failure and the entire software goes down, the business will point as an IT fault. The business doesn't make a separation from Developers, Testers, DB Administrators, Service Desk and other roles and neither it should. Remember that IT should support the business itself not the other way around. That's why for NFRs I usually choose to account the entire IT department.

Why have I emphasised on my card to operate independently of each other with no problems? Well, that's main reason why you want your software like that. So in a case that you want to move from in-house to cloud you won't have to do code refactoring for everything. And putting by that way a non-technical folk as other stakeholders will still be able to see the real value of having a software that is written using this good practices.

What do you think? Do you agree on my approach?