Determining and documenting the requirements for your latest software development project are almost always the single largest reason for the success (or the lack thereof) of a software development project. It does not matter if the project is being created from a bare-bones starting point, a feature add-in to an existing software app or when a project is in a pre-sales mode, requirements get naturally meatier as the timeline progresses to a point where development can begin. While a detailed/elaborate set of requirements is most certainly more welcomed by developers and architect alike, but the quality of these requirements solely depends on the team or source with the client organization.
Who are the “right” stakeholders?
The starting point for most requirements documents come from IT stakeholders and are in plain English with adequate stress on conveying the information accurately. It is natural that different stakeholders have different interpretations of what a system should do. When the right stakeholder fails to be heard, the requirements that are documented are not consistent with user needs. The best set of requirements set needs to be validated by every stakeholder that would use the system.
With development methodologies such as iterative and agile development becoming just as common place as traditional SDLC, the emphasis on requirements and their definition has remained unchanged. The best, most effective way for requirements to be collected is with moving toward an active collaborative model where users from every level of the customer’s ecosystem are considered by IT managers and CIOs. In fact, a Gartner survey from 2008 found that active collaboration is an essential element for successful information system and service projects.
To get the best requirements for use with inhouse or external software development teams, active collaboration is the key element to gather correct and relevant requirements. To do this an active collaboration team must follow the following procedures:
- Initial set of high-level requirements: Brainstorming, interviewing end-users, story-boarding of workflows, surveys or workshops to gather information
- Validate the initial requirements to ensure the user experience is fully taken into account
- Users must correct any discrepancies and fine tune
- Ensure all the final requirements are logical and consistent with the end-user’s needs: Encourage end-users to share their challenges with the current application or product
Active collaboration between developers, stakeholders and especially end-users should help focus the attention on the what and not the how. Developing SMART (Specific, Measurable, Achievable, Realistic, Timely) requirements is a steadfast process to help identify and understand problems that have been unresolved by previous applications. Utilizing an active collaboration model will provide a solid foundation for design and development which goes a long way to ensure the development process solves the right problem.
What are the types of code requirements? Why do they matter?
There are basically two types of software requirements – Functional and Non-Functional. As the name implies, Functional requirements describe the functionality of the product and what tasks the software must perform and will include:
- The scope of the system
- The product boundaries
- The product’s connections to the adjacent systems
Functional requirements also define the business rules. Business rules are the rules that the system must conform to, based on the individual business. This includes defining the data that must be tracked.
The business rules are the most important type of functional requirements and most of your requirements will be of this type.
Non-Functional requirements describe the look and feel of the system. This includes the visual properties of the system, its usability, and the performance requirements – how big, how fast, etc. Non-Functional requirements also include the product’s intended operating environment and any maintainability, portability and security issues. Non-Functional requirements also include cultural and political issues as well as legal requirements that the software must conform to.
What is a Requirements Traceability Matrix? What’s the benefit? When is this needed?
Requirements Traceability Matrix or the RTM document is needed to capture all requirements proposed by the active collaboration team or software development team and their traceability in a single document delivered at the conclusion of the product life-cycle process.
In other words, it is a document that maps and traces user requirement with test cases. The main purpose of RTM is to see that all test cases are covered and that no functionality is missed while conducting the required software testing.
In order for you to create a requirements traceability matrix you must understand the differences in non-functional and functional requirements and their importance to the application.
What are the top reasons you should have a RTM?
The success of your project may be determined by how well it was delivered. Whether your team uses Agile or Waterfall, Exploratory or Traditional Testing, Test-driven development or other methodologies, you need to be able to determine whether you’re delivering to the business requirements.
#1 Test Case management tracking improvements are tied to traceability effectiveness.
#2 Version Handling is an integral part of the matrix. This document allows you to track every change to a requirement, from the parameters, to the actual requirements description, related links and attachments. When used correctly, the team can look back at the end of the sprint to deliver the product as requested.
#3 Integrations and tool management is seamless. Overcoming the challenges of using multiple tools to run a successful project. Using a good traceability matric to give you the ability to keep track of the progress from requirement though to the defects yielded from the test cases.
#4 Defect handling improvement. After you finalize the scope of your project, you will pick up high-priority requirements and defects that will need to be fixed. The RTM will allow teams to sift through the defects to zero in on the defects that are priority.
#5 Documentation is built in to a RTM and good requirements document. It is hard to ignore the benefits to the entire team for clear documentation and communication.
Combining all the knowledge
Often, development teams, as well as customers, feel like they aren’t being “productive’ when they are working on the design instead of producing code. However, applications that are well-planned and built with a solid design are actually less time consuming to build, more flexible and scalable, and easier to maintain than those built by trial and error.
Collecting and documenting requirements and designing an adequate traceability matrix may be a very tedious process, especially for large projects. However, it is a necessary part of the development process, and once you get comfortable with it and view it as a necessary tool for software design, your project is sure to succeed.