It has been a while since posting on this blog. Apologies to my readers, Ascend has been growing at a rapid pace thanks to our Agile project management and software development methodologies. As we continue to pick up steam, it is important for us to remind ourselves and others the importance of Agile project management. Also, please enjoy the Vince Vaughn business stock photos. I always found these to be hilarious.
Do Agile Projects Need Requirements Analysts?
Within Agile projects, project roles associated with a traditional Waterfall based Software Development Life Cycle (SDLC) are given at times new names, and new definitions. Many agile projects have team members wearing multiple hats at any one time, for instance a SCRUM Master, a common role within an Agile / SCRUM project, may also be the lead developer or architect.
The Requirements Analyst is the important in-between for the business owner / client and developer. They help facilitate, elicit, capture, translate, and communicate requirements between the business owner / client (who gives the requirements) and the developer (who incorporates or builds the requirements into a system). The Requirements Analyst, for all sense and purposes, is a necessary step in the development process. Often times, developers cannot be a requirements analyst, as they are more focused on building the system, not capturing the details of the system to be built. This is not always true, but often times, at least in my experience, a developer would rather troubleshoot his code for hours than spend time in a meeting trying to figure out what a business owner or client is conveying in regards to the system.
When are Requirements Captured?
One of the major differences found between Agile and traditional Waterfall methodologies is the use of iterative development to achieve a desired product for the customers. As a requirements analyst in an agile project, requirements are captured iteratively within a Sprint or iteration of the software. Unlike a traditional SDLC, the business owner / client does not need to know all the requirements upfront. Only the broad scope, or vision of the project is defined, with all requirements captured adhering or mapping to this vision.
As the project progresses, the team can see the software take shape. As the software takes shape, the client can provide feedback and experience the way the requirements were interpreted and implemented. From a requirements analyst perspective, they continue to capture the client’s or business owners’ needs (and may I emphasize needs, not wants), and ensure these points fit within the vision of the product.
How are Requirements Captured?
Prior to the beginning of a project, the Requirements Analyst must understand the stakeholders, both from a political and systems usage perspective. Requirements will need to be implemented, and many may be given by different stakeholders. Subsequently, if a Requirements Analyst does not understand the different kinds of users / stakeholders, the system will not be properly designed. Stakeholders must be defined in the vision.
Within each iteration, additional requirements are captured. Requirements are captured into User Stories. A user story represents a statement of a piece of functionality a user wants to see. It replaces the traditional “The System Shall…” statements. User Stories are captured from the users’ point of view, and speaks to the typical piece of functionality a user would like to see in the system. The template looks as follows:
As a <user> I want to <do something> so that <something happens / goal is satisfied, etc.>.
These User Stories are captured, stored and prioritized in the Product Backlog. User stories can be captured using traditional requirements gathering techniques, including interviews (single one-on-one and group), focus groups, and surveys.
What Modeling Techniques are Used?
One of the main points / principles of the Agile Manifesto is the delivery of “Working Software over comprehensive Documentation.” What does this mean? Well, according to the Agile Manifesto, it is better for us to develop software, which is working, rather than analyzing, re-analyzing, and continuing to develop out documentation, which may have little or no use to the project itself.
Several of the Agile prescribed modeling techniques include building out a usage model, UML models, and a user interface prototypes.
- Usage Model: Exactly what it sounds like, it is a collection of user stories or use cases on how the system will be used. Often times these are documented in either documents, cards, and subsequently prioritized.
- Unified Modeling Language (UML) Modeling: Many of the UML Models and diagrams go to painstaking detail to describe how a system shall function. Rather than spending time ensuring all these painstaking levels of detail, it is often better to use a Class Diagram, for object orientation and to describe an object’s methods & properties. The Use Case Diagram is another excellent UML diagram, showing how different users will interact with the system.
- User Interface Prototypes: Getting the system to look correctly is arguably as important as getting the system to function properly. A UI Prototype / Diagram conveys to the client / business owner how the system will look when it functions. The UI Prototype also allows developers to visually see how the system may look. It is important to note that UI Prototypes should have an accompanying explanation to each of the elements, speaking to their functionality and purpose.
Conclusion
The requirements analyst is a necessary and important role within both traditional Waterfall SDLC project teams and Agile project teams. They are the liaison between the business owner / client and the developers, capturing, eliciting, and documenting requirements. The requirements analyst uses a variety of techniques to ensure the requirements are captured correctly, developed, and implemented per the business owner’s / client’s expectations. Whether working in an Agile or Waterfall SDLC environment, it is important to always note the Requirements Analyst represents the voice of the client, and is an important role which helps the system tasks / user stories “get to Done.”