When

Tuesday September 22, 2015 from 6:00 PM to 8:00 PM PDT
Add to Calendar 

Where

Mercer Island Community and Event Center 
8236 SE 24th Street
Mercer Island, WA 98040
 

 
Driving Directions 

Contact

IIBA Seattle Chapter 
 
info@seattle.iiba.org 
 

IIBA Seattle Chapter Event -
Requirement Management

by Leslie Munday

Requirements Management is the processes and guidelines for ensuring that your requirements are:

  • Testable
  • Complete
  • Consistent
  • Feasible

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?

  • To satisfy the customer that their needs are being met.
  • Allows project management to be able to estimate the cost (in money, schedule and resources), of changes to the requirements.
  • To ensure that developers are building the right product.
  • Allows testers to ensure that the product that was built meets the need of to the requirements.

What types of traceability?

  • Traceability from business needs.
  • Traceability to design.
  • Traceability from changes to requirements.
  • Traceability between requirements.
  • Parent/child type structure decomposition of requirements.

Tools and examples

  • Documents written with a word processing tool, such as MS Word.
  • Spreadsheet tools, such as MS Excel.
  • Purpose built traceability tools, such as Rational RequisitePro.
  • Content management tools, such as MS SharePoint.
  • Diagramming and modeling tools, such as Visio and Enterprise Architect.

Pitfalls and disadvantages of traceability

  • Complexity and time to maintain.
  • Partial traceability.
  • Performing traceability without understanding the benefits to the project.
  • The human cost.

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:

  • Software Development Life Cycle (SDLC)
  • Business process improvement and modeling tools
  • Unified Modeling Language (UML)/Rational Unified Process (RUP)
  • Agile/Scrum development
  • Project Management
  • Requirements analysis and management tools
  • Microsoft Office and SharePoint
  • Business and functional requirements specification documents

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.