Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements Engineering Diagnostic and Process Improvement - Coggle…
Requirements Engineering Diagnostic and Process Improvement
System
Project Perspective
The Project Perspective describes the context and origin of the system
System Context
The System Context describes the resulting software within the businesscase, including strategic issues in which the system is involved or which itspecifically addresses.
General Constraints
General Constraints identify any business or system constraints that willimpact the way in which the software is to be
specified·
designed·
implemented·
tested
Assumptions and Dependencies
List any assumptions that have been made during the start of the project.
Domain Model
Class Diagrams
Class Diagrams use classes and associations to describe the static structureof a system (e.g. UML Classes).
Classes represent abstractions of objects
Associations represent the structural relationships
Class Specifications
Class Specifications, or Definitions, define and describe each class in atextual way
Prototyping
is a process designed to reduce riskby validating or deriving the final system requirements.
Throw-Away Prototyping begins with the requirements that are unclear or poorlyunderstood.
it is expected that the prototype will deployed and demonstratedon the stakeholder
Requirements
Use Case Requirements
Specify each individual functional requirement that must be supported bythe system.
Use Case Diagrams
Use Case Diagrams shows actors and Use Cases.consist of using “include” and “extend”relationships
Actor list
An Actor is anything with behaviour; examples are system, acompany, an organization, or a role played by a person.
Use Case Specifications
Every Use Case must have a corresponding textual specification,helping the reader to focus on what is essential in terms offunctional requirements.
Activity diagrams
a diagram that describes a sequence ofbusiness or system activities.
Business Use case
A business Use Case is a business process representing a specificworkflow in the business.
Business Rules
might be used for documentingcomplex business rules.Projects without complex business rules may instead document businessrules in the notes or comments section of the relevant Use Case
Non-Functional Requirements
for a system are typically constraintson the functional requirements – that is, not what the system does, buthow it does it
System Requirements
Provide a comprehensive but high-level description of thetechnologies, if known, that will compose the target systemenvironment.
Usability Requirements
Describe the expectations regarding to how easy the system will beto use.
Performance Requirements
Describe the requirements for system performance, in terms of thefollowing: speed,safety,precsion,Reliability,Availability,Capacity
Security Requirements
Specify the requirements for protecting the system from accidentalor malicious access, use, modification, destruction or disclosure.
Delivery Requirements
Provide details of the life cycle and approach that will be used todeliver the system.
Legal Requirements
Define any legal requirements that the system must support,explain whether the system falls under the jurisdiction of any law
Interoperability Requirements
Define any requirements relating to interoperability with relevantsystems
Scalability Requirements
Define any requirements relating to scalability.
Interface Requirements
Machine Interfaces
Describe any interfaces to other machines, computers or devices
External System Interfaces
Describe any interfaces to other systems, products or networks.
Human-Computer Interface Considerations
rovide screen images and associated text, note and describe anyprinciples concerning the Human-Computer Interface,
Input and Output Requirements
Define the inputs and outputs of the system and or businessprocess. The definitions include the source, medium and type aswell as any enablers or guides that help with the process.
Project/Release Issues
Projected Development Effort
Provide a high-level description and estimate of the project developmentefforts. This estimate includes the estimated effort required
Proposed Project Schedule
Documents the high-level project schedule, which is based upon the effortdescribed in the previous section
9-12 month
Conversion / Load Requirements
Data Population Load
The data population strategy is to be specified in this section.Applications that are being developed to replace a current systemare likely to have complex data conversion requirements.
Reference tables and Baseline Data Load
Describe the strategy for populating reference tables and baselinedata.
Data Conversion Strategy
Describe the strategy for populating the application with data. Ifdata is being converted from a legacy system, describe therequirements and approach to be followed.
Data Conversion Assumptions and Constraints
Identify any assumptions or constraints that may limit or constrainthe data conversion requirements.