Analysis Concepts & Principles

4:50 AM / Posted by Alagan /

1.0      Requirements Analysis

  • Requirements Analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model.
  • Requirements are a description of how a system should behave or a description of system properties or attributes.
  • It can alternatively be a statement of ‘what’ an application is expected to do, not ‘how’.
  • Software engineering task that bridges the gap between system level requirements engineering and software design.
  • Software requirements analysis may be divided into give areas of effort
    • Problem recognition
    • Evaluation and synthesis
    • Modeling
    • Specification
    • Review
  • Requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users.
  • Requirements analysis is critical to the success of a project.
  • It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification.
  • The term “requirements analysis” can also be applied specifically to the analysis proper.
  • Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
  • Five common errors in requirements analysis:
    • Customers do not really know what they want
    • Requirements change during the course of the project
    • Customers have unreasonable timelines
    • Communication gaps exist between customers, engineers and project managers
    • The development team does not understand the politics of the customer’s organization

2.0      Requirements Elicitation for Software

  • Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process.
    • Initiating the Process
      • The most commonly used requirements elicitation technique is to conduct a meeting or interview
    • Facilitated Application Techniques
      • This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of solution, negotiate different approaches and specify a preliminary set of solution requirements
    • Quality Function Deployment
      • A technique that translates the needs of the customer into technical requirements for software
      • QFD identifies three types of requirements
        • Normal requirements – the objectives and goals that are stated for a product or system during meeting with the customer
        • Expected requirements – these requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them
        • Exciting requirements – these features go beyond the customer’s expectations and prove to be very satisfying when present
    • Interviews
      • A “traditional” means of eliciting requirements.
      • It is important to understand the advantages and limitations of interviews and how they should be conducted.




    • Use-Cases
      • As requirements are gathered as part of informal meetings, FAST, or QFD, the software engineer can create a set of scenarios that identify a thread of usage for the system to be constructed.
    • Prototype
      • A valuable tool for clarifying unclear requirements.
      • They can act in a similar way to scenarios by providing users with a context within which they can better understand what information they need to provide.
      • There is a wide range of prototyping techniques, from paper mock-ups of screen designs to beta-test versions of software products, and a strong overlap of their use for requirements elicitation and the use of prototypes for requirements validation.

3.0      Analysis Principles

  • All analysis methods are related by a set of operational principles
    • The information domain of a problem must be represented and understood
    • The functions that the software is to perform must be defined
    • The behavior of the software must be represented
    • The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion
    • The analysis process should move from essential information toward implementation detail
  • In addition to these operational analysis principles, a set of guiding principles for requirements engineering are suggested as
    • Understand the problem before you begin to create the analysis model
    • Develop prototypes that enable a user to understand how human/machine interaction will occurs
    • Record the origin of an the reason for every requirement
    • Use multiple view of requirements
    • Rank requirements
    • Work to eliminate ambiguity

4.0      Specification

  • Specification principles
    • Separate functionality from implementation
    • Develop a model of the desired behavior of a system that encompasses data and functional response of a system to various stimuli from the environment
    • Establish the context in which software operates by specifying the manner in which other systems components interact with software
    • Define the environment in which the system operates and indicate how “a highly intertwined collection of agents react to stimuli in the environment (changes to objects) produced by those agents”
    • Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community
    • Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A specification is always a model-an abstraction-of some real situation that is normally quite complex. Hence, it will be incomplete and will exist at many level of detail
    • Establish the content and structure of a specification in a way that will enable it to be amenable to change


  • Representation
    • Representation format and content should be relevant to the problem
    • Information contained within the specification should be nested
    • Diagrams and other notational forms should be restricted in number and consistent in use
    • Representations should be revisable


  • The software requirements specification
    • Is produced at the culmination of analysis task.
    • The function and performance allocated to software as part of system engineering are refined by establishing a complete information description, a detailed functional description, a representation of system behavior, an indication of performance requirements and design constraints, appropriate validation criteria, and other information pertinent to requirements.
    • Format of software requirements specification:
      • Introduction
      • Information description
      • Functional description
      • Behavioral description
      • Validation criteria
      • Bibliography and appendix

5.0      Specification Review

  • A review of the Software Requirements Specification is conducted by both the software developer and the customer.
  • Because the specification forms the foundation of the development phase, extreme care should be taken into conducting the review.
  • Once the review is complete, the Software Requirements Specification is “signed-off” by both the customer and developer.
The specification becomes a “contract” for software development



Post a Comment