“The hardest single part of building a software system is deciding precisely what to build.”- Fred Brooks, The Mythical Man Month
What should we build? It’s a simple question, but for custom software applications it can be hard to answer. How do we make sure we’re giving our customers something that will really meet their needs? As a Requirements Analyst, I work to define the needs of Segue’s customers so we can translate those needs into software. Around the industry, people like me have various job titles: Business Analysts, Systems Analysts, Product Owners, User Experience Designers, or Requirements Engineers. Regardless of our titles, our objectives are the same:
- Define and understand the stakeholders’ true needs for their system or application
- Analyze those needs and turn them into useful requirements for software development
- Continually communicate the changing needs to the entire team
Defining business needs is tough, as there is a difference between how customers and end users view an application and how a software development team views it. Our customers know what they want from a business standpoint, but determining the appropriate technical solution can require asking questions they hadn’t considered. Requirements analysts repeatedly ask “Why?” until the true needs are understood. For example, our clients may ask for a Web application that gives their employees the ability to easily collaborate on and review documents through a defined workflow. However, this tool will need to integrate with the larger business system, and it has to work for the people and the organization. Understanding what kinds of documents will be used by the system, and how the users will access the system (Web browser versions, inside a network or remotely on a mobile device, etc.) are all considerations that may have been outside of the customer’s original vision, but have direct and significant impact on how the system is developed.
Remember, I’m a Requirements Analyst, so it is my job to go below the surface of the expressed need. Analysis is where a need is refined and transformed into a specific “requirement”, which is something a development team can enact. Requirements are often formally written specifications or use cases. But a great requirement could just be a wireframe drawing of a screen with items arranged a certain way, or a well-written user story describing a user performing an action and reaching a goal. Laws, such as the federal Section 508 rules, are also requirements that must be defined for an application. Whatever form it takes, a good requirement should be complete enough so a Developer can write code for it, a Quality Control Analyst can test it and a customer can confirm “yes, this is what I need.”
Communication is the heart of requirements. It’s important to understand that requirements always change and evolve and everyone has to understand those changes when they occur. As team members, Requirements Analysts try to make sure everyone has the information they need. We work closely with software developers, answering questions and translating client input and we help evaluate possible solution alternatives. We help facilitate meetings where prototypes are reviewed and work with customers. We support Quality Control, providing test scenarios or even doing some testing ourselves. We advise Project Managers on priorities and features. Through it all, we continue to analyze and clarify the requirements. Some Requirements Analysts also provide Help documentation and user manuals, or training for end users. Because we have a good understanding of the clients’ needs, we are good resources throughout the life of the project.
My goal as a Requirements Analyst is to deliver value to Segue’s clients. As a company we develop custom software tools for our customers business needs, and I play a key role in ensuring they get what they need, not only on the surface, but a solution that truly makes sense from all aspects.
What should we build? A Requirements Analyst can always help answer this difficult question.