Seilevel provides teams of expert Requirements Architects, Product Managers, and Requirements Analysts to help you:
- Determine the project’s business objectives and desired outcomes.
- Plan your requirements efforts, execute on requirements elicitation and facilitation.
- Create a full set of visual models for the requirements.
- Create any needed requirements documentation.
- Manage changes to requirements throughout the entire project lifecycle.
- Transition requirements knowledge to development and test teams.
- Measure the success of the project.
Seilevel’s requirements approach fits into any methodology (SCRUM, RUP, waterfall, iterative, and others). The diagram below shows a few examples of where Seilevel can add value in your projects. Click on the diagram to enlarge it.
A few of the most impactful areas include:
Identify Business Objectives – Business objectives are the single most important thing that every project should understand and define so that all efforts can be prioritized against the value that the project is delivering to the business. Some projects will need additional definition around key performance indicators (KPIs) as well, to ensure that they maintain performance standards from existing systems and processes in place as replacement systems are deployed.
Cut Scope – Most features in software are never used, so it’d be better to cut them up front and never develop requirements for them or implement them in the software. Significant time and money can be saved by making drastic scope cuts. Business objectives can be used to evaluate the dollar value contribute of features and compare, cutting the ones that contribute the least to the overall business value.
Elicit Requirements – There are many different techniques to elicit requirements and their priorities, including workshops, facilitated interviews, observations, or prototypes. The techniques used on your project will be very specific to the type of project, the stakeholders, the stage, and even the type of organization. Most projects require some combination of many elicitation techniques.
Visually Model Requirements – Requirements models are essential to communicate requirements in a consumable way and to ensure that requirements are not missing during analysis. The 22 models from RML® (Requirements Modeling Language) are designed to be easy to create and use by anyone on the team, many of them even can be created by the business users.
Transition Knowledge – As requirements efforts progress, the business and the business analysts and product managers increase their knowledge about what they want the end product to be. It’s important though that the development and test team gain that same knowledge, rather than tossing some specifications over the wall to them. It is useful to track issues against requirements throughout this activity to track their questions about requirements because a lack of issues is great indication that teams are not consuming sections of your requirements.
Manage Requirements Change – One thing is constant on all projects, and that is that requirements and their priorities will change. It is important to have a process in place that works for your organization to whatever level or rigor (or lack therefore) is appropriate. The hardest part of this is as lead stakeholders change or business priorities evolve, requirements might change, but more likely, their priorities will change and the scope of the project will change accordingly.
Deploy Solutions – In order to ensure successful user adoption of the new software, careful attention needs to be paid to training materials and user acceptance tests. Various requirements models, like Use Cases, can be used to create user acceptance test scripts that the business users can execute. Similarly, many of the models can be converted into training materials so they can learn about the new system while minimizing training material development effort.
Evaluate Success – Excellent requirements are never the goal. The real end goal is to deliver successful products. Success is very specific to a business’s needs and the criteria for success is set early by understanding business problems and business objectives. After a project launches, the success should be measured to determine what additional changes are needed, such as additional features, training, or maybe marketing support. The goal is to maximize the return on investment and learn for future projects, and the only way to do that is to understand what it is after projects are done.
All of these requirements-related activities are important to delivering successful projects at a lower cost and on time. Seilevel teams use our proven requirements approach adapted to our customer’s methodology and culture. All of our requirements practitioners are trained and certified in our requirements approach.
Seilevel has unparalleled credentials in software requirements. Two of our Requirements Architects have written a book, Visual Models for Software Requirements, published July 2012 by Microsoft Press. One of Seilevel’s Requirements Architects is an International Institute of Business Analysis (IIBA) Certified Business Analyst (CBAP) who currently serves on the committee to write the next version of the IIBA Business Analysis Body of Knowledge (BABOK).