Requirements Management is the processes and guidelines for ensuring that your requirements are:
What is Requirements Traceability?
Requirements traceability is concerned with managing the lifetime states of a set of requirements. Traceability makes it possible to locate the origin of each requirement and the reason for every change made to the requirement. Traceability can therefore be documented in order to justify the implementation and deployment of a requirement from its original inception.
Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements for the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation. This can, for example, be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment when user studies show that a feature is not used, to see why it was required in the first place.
Why is traceability important?
What types of traceability?
Tools and examples
Pitfalls and disadvantages of traceability
Leslie Munday is a Business and Systems Analyst with over 25 years of IT experience of Software Development Life Cycle (SDLC) with Agile and waterfall, Project Management, Business Process Improvement and Documentation Skills. He began his career as a software developer working for Marconi and British > Aerospace. He moved to Canada in the early 90’s to join the Space Station project as a systems Analyst during development of the Canadarm2. Leslie moved to Seattle in the late 90s to join a mobile communications company. Since moving to the Seattle area he has worked as a contractor and full-time employee in several industries. Employers include Nike, Microsoft, AT&T, Premera and Regence - as either a systems analyst, business analyst or project manager; often taking on 2 roles at the same time.
Leslie’s areas of expertize are:
SDLC Experience
Working in a highly regulated waterfall environment, Leslie used the UML with Rational Tools while working on the Space Station. When he moved the Seattle to work with telecommunications systems he introduced the RUP to several companies. At Nike he assisted with defining process for RUP and UML into the IT department. He worked as a process analyst for AT&T, Nike and Regence, defining process for a variety of iterative SDLCs, including RUP, MSF and Shlaer/Mellor. More recently, Leslie has been working with agile process definition for Scrum projects.
Business Analyst Experience
Leslie gained his first role as a pure business analyst while working at Nike, eliciting requirements from line planning stakeholders. Since then he has been a business analyst on various health insurance projects, for Washington State ferries reservation system project and most recently for Nordstrom’s copy writing process.
Systems Analyst Experience
Leslie joined British Aerospace as a systems analyst during development of the A330/340 Airbus aircraft. He was a systems analyst on the Space Station for 8 years. More recently he has played a systems analyst role for various telecommunications, ecommerce and health insurance projects.
Process Improvement Experience
Leslie assisted with documentation and modeling standards on the Space > Station project. Was responsible for the Requirements and Analysis and Design disciplines during the adoption of RUP at AT&T. He defined a requirements management methodology for Microsoft and was also responsible for planning and adoption of Rational tools and the UML at Regence. He wrote quality requirements standards for Wizards of the Coast. Recently he has assisted with agile standards for defining and managing requirements and user stories for Scrum projects at Premera and AT&T.
Project Management Experience
Leslie was the project manager for development of Hollywood Video websites and Design Within Reach ecommerce projects.