Requirements Gathering and Analysis: The Second Step in Software Development

Once the visioning phase is complete, it is time to gather and analyze requirements for your software project, system or whatever else you are planning. At this point, it is often useful to identify a smaller subset of the stakeholder group who can work intensively with you on this (although all stakeholders can be included, if the group is small). This is also a good time to bring together stakeholders and key members of the development and implementation team.

Generally, requirements gathering and analysis happen over a series of meetings (at least two). I find it best to do it freeform and capture ideas on whiteboards; more formal documentation can follow later, or documentation can remain informal if the project doesn’t require it.

Remember that this is only the first and most intensive stage of requirements gathering. Ideally, requirements should be continuously collected, documented, analyzed and refined throughout the development process.

These are the general goals for the first couple of requirements meetings:

• Create a context diagram, which is usually a rough drawing of the system and its context, based on previous goal-setting with the stakeholders.
• Define actors and their goals. Actors are the primary users of the system. Ask what specific activities are each actor trying to achieve?
• List initial use cases in brief narrative. Ask how each actor will achieve each goal, but don’t try to get too detailed at this point.
• Begin capturing terms to include in the glossary as they come in up in the discussion.
• Identify business rules that provide constraints on the system (based on the givens identified during the vision stage plus others subsequently identified). Ask what we can and can’t do according to our organizational policies, laws of the land, requirements of our funders and so forth.
• Identify nonfunctional requirements (based on the givens, high-level goals and others subsequently identified). These requirements won’t be captured in the use cases but are important to document. They might include security, technology, system integration, localization, reliability and similar requirements.
• Identify working group members from the stakeholder group to call upon for testing and feedback as development progresses.

As requirements gathering progresses, drill down into detail on the requirements and document them thoroughly. The following goals may be accomplished in subsequent meetings or through a virtual collaborative space where stakeholders and members of the development team can post, read and comment on documentation.

• Write the initial set of high-priority use cases in full form.
• Document functional requirements, or inner operations of the system (calculations, technical details, data manipulation and processing, others) that will satisfy the use cases.
• Organize use cases and requirements into packages (or modules) to help guide development and figure out what should be tackled first.
• Create a project plan that maps out generally when each piece of functionality (or module) will be completed but that can be modified as the project progresses.
• Begin a project control list for documenting new features and areas of redesign and determining if and when they should be implemented as they come up during development.
• Begin an issue list (or bug tracker) for tracking problems and questions that arise and may need to be addressed by stakeholders or in a later development cycle. The issue list is distinguished from the project control list in that a feature or solution has not been determined yet to address the issue; once that is determined, the issue is closed and the item is added to the project control list.
• Create a well-organized project knowledge base with all documentation, including other pieces that may be needed at this point (workflow diagram, database design, network design, prototype, user interface mockup, etc.) that is accessible to everyone working on the project.
• Present the use cases and other relevant documentation to the working group or all stakeholders and receive sign-off to proceed with development.