Software Requirements Knowledge Model
Software requirements activity involves the interest of a number of parties and stakeholders. This model tries to capture them. StakeholdersGovernors-Board Members, Corporate Officers, Government Regulators. Requestors-Activity Managers, Solution Planners, Solution Marketers. Expectors -Customers, Installers, Maintainers Interests and ConcernsValue Relevance Profitability Growth Diversity
Software Requirements Conceptual Model
Level Level Level Level Level Level Level 0: 1: 2: 3: 4: 5: 6: Vision, Mission, Values Business Activity Activity Improvement Solution Feature Interaction Dialog Solution Component Development Project
This model answers the questionsHow defines the requirements? Why the requirements are necessary? What are the requirements? When are the requirements needful? Where are the requirements necessary?
Physical Object Model (OOP)
The physical object model treats each requirement as an object. Hardware-Hiding Modules. ³Programs that need to be changed if any part of the hardware is replaced.´ Modules for which the encapsulated information (secret) is ³hardware / software interfaces.´ Required Behavior-Hiding Modules. ³Programs that need to be changed if there are changes in the sections of the requirements document that describe the required behavior.´ Modules for which the encapsulated information (secret) is ³the content of those sections [of the requirements document].´ Design Decision-Hiding Modules. All other programs of the application. Modules for which the encapsulated information (secrets) are ³software design decisions based upon mathematical theorems, physical facts, and programming considerations such as algorithmic efficiency and accuracy . . . not described in the requirements document.´
State Diagram Model
State Diagram Model
Requirements can also be defined using the state diagram. The state diagram depicts requirements using the following methods1. Defining the processes. 2. Defining the flow of information. 3. Defining the information at each stage. 4. Defining the requirements of each process and user.
Software Cost Reduction Requirements Model
Specification Editor Consistency Checker
Dependency Graph Browser
Cost Reduction Model
Specification Editor. To create and modify a re-quirements specification, the user invokes the specification editor. Each SCR specification is organized into dictionaries and tables. Dependency Graph Browser. Understanding the relationship between different parts of a large specification can be difficult. To address this problem, the Dependency Graph Browser (DGB) represents the dependencies among the variables in a given SCR specication as a directed graph Consistency Checker. The consistency checker analyzes a specication for consistency with the SCRrequirements model. It exposes syntax and type errors, variable name discrepancies, missing cases, no determinism, and circular definitions. When an error is detected, the consistency checker provides detailed feedback to facilitate error correction. Simulator. To validate a specication, the user can run the simulator  and analyze the results to ensure that the specication captures the intended behavior. Theorem Prover. When model checking fails to reveal an error in a requirements specication or produces many spurious counterexamples, the user may use mechanical theorem proving to establish the property. Invariant Generator. Recently, a prototype tool that automatically generates state invariants from SCR tables was integrated into SCR. This tool has generated more than 20 interesting state invariants
Emphasizes completion of one phase of development before proceeding to the next phase; freeze the products of one phase before proceeding to the next phase. Must use a formal change mechanism to make requirements changes.
Patterned after process models in other disciplines, making it easy for managers to understand and accept. In this model each phase is defined by a set of functions, goals, milestones, and deliverables, making the process highly visible and the project easier to track. Since requirements and specifications are determined at the outset, the PM is better able to determine his or her resource needs and establish schedules.
Systems that have well-defined requirements at the outset and systems where the costs and schedules need to be determined up front.
Incremental Development Model
Performs the waterfall in overlapping sections. Requirements do not have to be fully specified/clarified at onset. As each increment is completed, requirements are clarified.
Well-suited for systems where the requirements cannot be specified.
The development stage is done as a series of increments. Each increment builds a subset of the full system. An increment is a full life cycle of analysis, design, coding, testing, and integration. It may be delivered to the user, but not necessarily. If it is delivered, there may be some finishing: optimization, packaging, and the like, after the build.
Is focused on early and continuous delivery of requirement defined stakeholder value. Allows detailed requirements to emerge gradually.
Well suited for systems where requirements cannot be specified
Divides system development into four basic activities: planning, risk analysis, engineering, and evaluation. Within each spiral loop, risks are identified and attempts to mitigate risk are made before proceeding to the engineering activity of the spiral.
Avoids some of the difficulties of existing software models by using a risk-driven approach. Tries to eliminate errors in early phases. Provides mechanisms for QA. Applicable to other kinds of projects. Works well for a complex, dynamic, innovative project. Reevaluation after each phase allows changes in user perspectives, technology advances, or financial perspectives.
Complex, dynamic, innovative, ambitious projects carried out in internal teams (not necessarily limited to software).
Unified Modeling Language
Unified Modeling Language
The Unified Modeling Language or UML is a mostly graphical modeling language that is used to express designs. It is a standardized language in which to specify the artifacts and components of a software system. It is important to understand that the UML describes a notation and not a process. It does not put forth a single method or process of design, but rather is a standardized tool that can be used in a design process. The Use Case Diagram In many design processes, the use case diagram is the first that designers will work with when starting a project. This diagram allows for the specification of high level user goals that the system must carry out. These goals are not necessarily tasks or actions, but can be more general required functionality of the system The Class Diagram The class diagram is core to object-oriented design. It describes the types of objects in the system and the static relationships between them. Interaction Diagrams - Sequence and Collaboration Once the use cases are specified, and some of the core objects in the system are prototyped on class diagrams, we can start designing the dynamic behavior of the system.
Black Box Model Of Requirements
Black Box Model
The benefit of the black box definition of requirements stems from the fact that, with requirements defined as the black box view of the system (i.e., its external interface), requirements become encapsulatable. A requirements (i.e., external interface) specification consists of: 1. All external stimuli of the system 2. All associated external responses 3. All external communication protocols
Enterprise Process Model
Enterprise Process Model
Before automating a task or process, a model of the customer¶s current mission or business process should first be developed. Usually this will be done as part of the customer¶s process improvement strategy when determining the cost±benefit to the customer of additional software. The steps includeBuild versus Buy Prioritize quality requirements Identify and Organize stimuli Sketch human user interface Depict external communication protocols Identify requirement commonalities Specify responses