According to the reference card published by Henny Portman in his post "Review Standish Group – CHAOS 2020: Beyond Infinity", only 31% of the projects are successful; and in PMI's Pulse of the Profession®(2020), many organizations reported poor requirements-gathering/management as the primary reason for project failure. This article aims to share professional observations on requirements engineering.
Types of Requirements
Based on my learnings, four types of requirements influence the success of a project:
Functional requirements are the capabilities needed by end-users of the software solution to fulfill their job. You can identify these requirements as they describe a use case, focus on its qualitative aspects and often answer questions that start with "what" end-users need.
Non-Functional Requirements define the expectations and characteristics that software systems should support. Sometimes they are named "ilities," yet the non-functional requirements can be split into two categories: runtime (i.e., performance, security, availability) or non-runtime (i.e., maintainability, scalability, testability). You can identify these requirements as prescriptive, use quantities, and often answer questions that start with "how well" the system should perform.
Constraints refer to things that cannot change in the current scope and lifetime of the project. They comprise budget, infrastructure limitations, available skills, standard technologies declared in the enterprise architecture. You can identify constraints as they often answer questions that start with "why".
Future requirements describe any constraints, functional or non-functional requirements that will change the software system architecture's evolution. You can identify these requirements as they often answer questions that start with "when".
Requirements Lifecycle
The above classification is useful for identifying the requirements during the requirements gathering phase of the project. In my opinion, requirements go through several states regardless if they relate to a single feature or the entire software project lifecycle:
In the given state, the requirements are sourced from different areas, like:
The project context specifies in business terms what the solution has to do. The set of objectives and assumptions used to frame the solution can be gathered from the project context. For example, it is important to get enough information about what are the dependencies between your solution and other ongoing or future projects; or position product or vendor assumptions.
The business case specifies the contextual market concerns and influences architectural decisions. For example, cost drivers can affect how and why you choose certain technologies.
The enterprise architecture specifies the assets (principles, patterns, standard building blocks, reference architectures) that may help ensure your solution architecture works in the context of the wider company.
These sources of requirements are gathered, analyzed, and translated into artefacts that ensure their acceptance by both stakeholders (business representatives) and the project team (implementation team). Requirements can be accepted when functional and operational aspects are captured (system context documentation), enough use cases are modeled, non-functional requirements and constraints are globally agreed upon. Some of you might consider the term of artefact as a document with archeological scope, written once and never to be changed, and such an approach is unfit for modern agile projects. Some examples of artefacts for agile projects include epics, user stories, prototypes. Throughout the project evolution, you should revise the globally agreed artefacts at the same pace as your implementation.
Acceptance of requirements is more than a formality; it represents an aligned understanding of project goals by stakeholders and the project team. Once this alignment occurs, the solution's implementation can go swiftly, regardless of its delivery methodology.
Validation of requirements can be done through functional and non-functional tests. In my opinion, a good set of functional tests include unit tests, integration tests, smoke tests, regression tests, and user acceptance testing. Regarding non-functional testing, I would recommend load testing, stress testing, compliance testing, usability testing. Still, as a general rule for non-functional testing, you should have tests for all the accepted non-functional requirements.
Final Thoughts
In my opinion, as a project's architecture evolves, revising the artefacts related to it is a team activity. Agile software delivery involves the democratic assignment of responsibilities and collective accountability for measuring team results and feedback. Thus I believe that maintaining architectural artefacts is equally important as code delivery, and every team member should contribute to both.
Comments