Home > Ask the Software Quality Experts > Software Requirements Gathering, Analysis, Quality and Testing Questions & Answers > Requirements discipline throughout the SDLC
Ask The Software Quality Expert: Questions & Answers
EMAIL THIS

Requirements discipline throughout the SDLC

Roxanne Miller EXPERT RESPONSE FROM: Roxanne Miller

Pose a Question
Other Software Quality Categories
Meet all Software Quality Experts
Become an Expert for this site


Software quality news and advice
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


>
QUESTION POSED ON: 01 April 2008
What two documents come after the requirements specification document?

>

Let's start by discussing requirements as a discipline performed in the context of a software application development process such as the Rational Unified Process (RUP) -- just to name one as a common reference. A documented, repeatable process such as Rational Unified Process places structure around the activities performed and the resulting artifacts, also known as deliverables. Related to the analyst's role, RUP includes the following disciplines:

  • Business modeling: Provides guidance for the analyst on how to understand and visually depict a business.
  • Requirements: Involves finding, maintaining and managing requirements for the business application. The business models developed in the business modeling discipline are a key input to these activities.
  • Analysis and design: Transforms the requirements into a design of the system-to-be and adapts that design to match the implementation environment, designing it for performance. The analyst can discover flaws in design. Change requests are generated and applied. Business entities in the business modeling discipline are also an input to identifying analysis and design solutions.
  • Implementation: Defines the organization of code, implements classes and objects, tests the resulting implementation elements, and integrates them into an executable system. This discipline includes developer testing -- that is, testing done by developers to verify that each developed element behaves as intended. This behavior derives ultimately, although often indirectly, from requirements captured by the analyst.
  • Test: Validates the system against (amongst other things) the requirements, ensuring that the system works properly. Requirements artifacts provided by the analyst are the basis for the definition of the evaluation activities.
  • Deployment: Describes the activities associated with ensuring that the software product and related materials are available for end users. The analyst produces the software requirements specification, which is one of the key inputs to development end user support and training materials.
  • Configuration and change management: Supports the analyst with the process of change, ensuring that changes are effectively documented and accepted during the lifecycle of the project. This also allows the analyst and those in other roles to do impact analysis.
  • Project management: Plans the project and each iteration and phase of the project. The requirements artifacts, particularly the requirements management plan, are important inputs to the planning activities. The driving forces behind the assessment and management activities are the requirements.
  • Environment: Develops and maintains the supporting artifacts that the analyst uses during requirements management and modeling.
  • Requirements discipline artifacts
    Now let's focus specifically on the activities and resulting artifacts of the requirements discipline -- again using Rational Unified Process as a common frame of reference:

    Activity Description Key resulting artifacts
    Analyze the problem Capture a common vocabulary, develop vision, identify end-user classes, and develop requirements management plan.
  • Glossary
  • Vision
  • Use case model
  • Requirements management plan
  • Requirements attributes
  • Understand stakeholder needs Capture a common vocabulary, develop vision, elicit stakeholder requests, identify end users and manage dependencies.
  • Glossary
  • Vision
  • Actor (user) list
  • Stakeholder requests
  • Storyboard
  • Use case model
    Supplementary specifications
  • Requirements attributes
  • Define the system Develop vision, capture a common vocabulary, identify end users and manage dependencies.
  • Glossary
  • Use case model
  • Supplementary specifications
  • Requirements attributes
  • Manage the scope Develop vision, manage dependencies and prioritize user goals.
  • Vision
  • Software architecture document
  • Requirements attributes
  • Refine the system definition Detail user goals and detail software requirements.
  • Supplementary specifications
  • Use case
  • Software requirements specification
  • Manage changing requirements Review requirements, manage dependencies and structure user goal modeling.
  • Review record
  • Use case model
  • Requirements attributes
  • The requirement artifacts as key inputs
    The artifacts resulting from the requirements discipline are inputs to the activities for the subsequent disciplines (for example, analysis and design) in the project lifecycle as shown in Figure 1. Within each of these subsequent disciplines are their respective activities and resulting artifacts.

    FIGURE 1: Rational Unified Process discipline relationships

    Summary
    There are numerous artifacts (deliverables) that follow the software requirements specification. That is, the software requirements specification is a key input to multiple activities and resulting artifacts within an application development process. A short list of examples of resulting artifacts from activities performed in disciplines that follow the requirements discipline is included in the table that follows. Each organization should define their application development process, which includes defined roles, activities and artifacts. The process should also indicate relationships between the roles and activities that span across each discipline in order to understand the order that activities are performed.

    Discipline following requirements Example RUP resulting artifacts
    Analysis and design
  • Software architecture document
  • Design model (e.g. data model, class diagram)
  • Use case realization
  • Change request
  • Implementation
  • Integration build plan
  • Test log/test results
  • Implementation element (e.g. source code)
  • Test
  • Test plan
  • Test strategy
  • Test script
  • Test results
  • Change request
  • Configuration and change management
  • Change control plan
  • Project repository
  • Deployment
  • Deployment plan
  • Training materials
  • Test evaluation summary
  • Installation artifacts

  • Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google



    RELATED CONTENT
    Software Requirements Gathering, Analysis, Quality and Testing
    Problems caused by skipping analysis stage of SDLC
    Software development life cycle phases, iterations, explained step by step
    Waterfall versus iterative development misconceptions
    Differentiating between Functional and Nonfunctional Requirements
    Writing a software requirements specification (SRS) for a portal app
    Should QA check changes from outside the requirements document?
    Software testing metrics for a medium-sized project
    Template for requirements use cases
    What should a business analyst's requirements document include?
    Is a requirements freeze in a software project a bad idea?

    Software Requirements Documentation
    VisibleThread aims to boost IT documentation quality, improve processes
    When it comes to requirements, what is 'just enough'?
    How to deliver, implement testable software requirements
    Blueprint rolls out Requirements Center 2010
    Writing a software requirements specification (SRS) for a portal app
    Should QA check changes from outside the requirements document?
    Agile software development tutorial: Agile requirements gathering
    Defining requirements during software project feasibility analysis
    Template for requirements use cases
    What should a business analyst's requirements document include?

    RELATED GLOSSARY TERMS
    Terms from Whatis.com − the technology online dictionary
    functional specification  (SearchSoftwareQuality.com)
    requirements analysis  (SearchSoftwareQuality.com)
    Software Engineering Institute (SEI)  (SearchSoftwareQuality.com)
    software requirements specification  (SearchSoftwareQuality.com)
    Wirth's Law  (SearchSoftwareQuality.com)

    RELATED RESOURCES
    2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
    Search Bitpipe.com for the latest white papers and business webcasts
    Whatis.com, the online computer dictionary



    Search and Browse the Expert Answer Center
    Search and browse more than 25,000 question and answer pairs from more than 250 TechTarget industry experts.
    Browse our Expert Advice



    Software Quality - Software Maintenance, Software Requirements, Software Standards
    About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
    SEARCH 
    TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

    TechTarget Corporate Web Site  |  Media Kits  |  Site Map




    All Rights Reserved, Copyright 2006 - 2009, TechTarget | Read our Privacy Policy
      TechTarget - The IT Media ROI Experts