Behavioral Analysis

Step One: Use Cases

The work begins by collecting and prioritizing use cases from different user perspectives and user types. This is an interactive, facilitated, open and divergent brainstorming process.

  • Capture an initial list (asking questions)
  • Categorize into primary, secondary, and unexplored (the team may generate many use cases)
  • Stack rank or rank by grade (high, medium, low)
    • Criteria for ranking = business value, user value, governance requirements, etc.
    • Where is richest or most important insight likely to be?
  • There is an opportunity for early attention to risk management in this process. It is suggested to keep the project Risk Register nearby during use case development to capture potential risks as part of the qualitative risk analysis process.

Continue in an iterative fashion to create a rich collection of requirements with detail. Prepare and maintain a separate summary level view for stakeholder communication, review, and comment. Keeping stakeholders engaged throughout this stage of project design will lead to converging expectations on what the system will in fact do when finished.

  • Capture the “Why” during development to enable context refresh when change is analyzed the future.

Step Two: Behavioral Relationships

The objective is to determine the required behaviors of the system. By carefully exploring individual use case behaviors, the analysis leads to detailed requirements. This is where thoughtful prioritization of use cases contributes to good use of team member time.

The process utilizes behavior scenarios: initiating event, subsequent activities (system, external, people), and final event(s).

  • Initial conditions must be specified
  • Ending conditions can determine measure of success

As we walk through each behavior, we ask “What must the system do?” and determine individual requirements step by step. Structured documentation is important showing behavior relationships between requirements and entities both internal and external to the system boundary. The use of a spreadsheet or more robust tools for complex systems is recommended.

Here is a simple (spreadsheet) example of a remote monitoring system:

Initial conditions, ending conditions, and notes should be documented.

Step Three: Originating Requirements

  • This relationship or behavior matrix is then simplified by examining only the system requirements, first in an unordered list.
  • Work proceeds to group, identify similarities, simplify and create a view of requirements by category.
  • Next a single requirement description is created for each category that accurately encompasses all the requirements.
    • This will produce a higher level of abstraction to facilitate project design
    • Create the final set of Originating Requirements (what the system must do but not how)
      • Function Names for each originating requirement are helpful assocations for design, and wbs development (listed after each originating requirement in a tabular fashion).

Step Four: Validation

  • Facilitate a validation exercise with key stakeholders illustrating with high priority use cases. Owner or sponsor approval of originating requirements is required.
  • Consider how acceptance criteria should be defined; develop initial matching acceptance test scenarios.
    • Performance Requirements-“How well it needs to be done”, and verifiable
    • Requirements Traceability Matrix
  • Consider development and schedule feasibility, change impact, and sustainability
  • Summarize and finalize to document functional requirements (potentially by audience)
    • A requirements baseline is a good practice, combined with a configuration control process.