Sometimes, when we think about the best strategy to ensure the success of an IT project, and therefore, a software project, we start thinking on how skilled and experienced the Developers should be, the software technology reliability, how much time we must spend on the Quality Assurance of the product, etc.; but we often lose the key factor that comes first than anything else, and is the basis for a successful IT project: Good Requirements!
During this series, we’ll show the paramount concepts of this ‘magical’ topic on a way that will be useful and applicable for the main team role players: Business Analysts, Developers and Quality Assurance Engineers.
Before we start, there are three key concepts we should bring to the table and that is important to keep in mind:
1. SDLC – Software Development Life Cycle. Regardless the standard or methodology that is applied, the requirements are used as an input among all stages.
2. [Business VS System] Analysis. As the requirements are a result of the work performed by the Analysts, during the Analysis, it’s relevant to understand the classic and modern approaches of the role/activity.
The classic approach from the analyst roles is based on the main difference related to the emphasis:
- Business analysts → Concerned about the business and how to use IT to achieve business goals
- Systems analyst → Concerned about software development and implementation
The modern approach from the analyst roles is based on a fusion of the two ‘old fashion’ roles:
- A BSA – Business Systems Analyst – is not a programmer, a software tester or a database administrator. The BSA works with the business to understand its needs, but he/she focuses on the business’ needs related to information technology.
- Using the knowledge of the organization’s technology infrastructure and specific software applications, the BSA help the business to address changes through technology.
3. Requirement Types – Because as a BA, QA, or Dev., we will interact with Requirements, we should understand the different types, for this we will use the BABOK ® Guide v2.0. as a reference.
- Business Requirements: Higher-level of goals, objectives, or needs of the enterprise.
- Stakeholder Requirements: Statements of the needs of a particular stakeholder or class of stakeholders. They serve as a bridge between Business and Solution Requirements.
- Solution Requirements: Describe the characteristics of a solution that meets business requirements and stakeholder requirements.
- Functional: Described the capabilities which the system will be able to perform – behavior and operations, actions or responses.
- Non Functional: Describes environmental conditions under which the solution must remain effective or the qualities that the system must have – capacity, speed, security, availability, etc.
- Transition: Describes capabilities the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.
Now that we have all this information in mind, we are able to start talking about a couple of themes that will enhance the way in which we interact with the Requirements.
