Lesson 6 Flashcards
The descriptions of what the system should do —the services that it provides and the constraints on its operation
Requirements
reflect the needs of customers for a system that serves a certain purpose such as controlling a device, placing an order, or finding information
Requirements
The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed.
Requirements Engineering
The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.
Requirements Engineering
high-level abstract requirements
User Requirements
statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate
User Requirements
more detailed descriptions of the software system’s functions, services, and operational constraints (what the system should do)
System Requirements
(sometimes called a functional specification) should define exactly what is to be implemented
System Requirements
It may be part of the contract between the system buyer and the software developers
System Requirements
What are the Readers of Different Types of Requirements Specification?
The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers who are not interested in the detailed facilities of the system
The readers of the system requirements need to know more precisely what the system will do because they are concerned with how it will support the business processes or because they are involved in the system implementation
Any person or organization who is affected by the system in some way and so who has a legitimate interest
System Stakeholders
What are the types of stakeholders?
- End users
- System managers
- System owners
- External stakeholders
ESSE
statements of services that the system should provide
Functional Requirements
It may explicitly or not states what the system should and should not do
Functional Requirements
These requirements depend on the type of software being developed, the expected users of the software, and the general approach taken by the organization when writing requirements
Functinal Requirements
usually described in an abstract way that can be understood by system users o More specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail
Functional user requirements
Varies from general requirements covering what the system should do to very specific requirements reflecting local ways of working or an 11 organization’s existing systems
Functional system requirements
functional requirements specification of a system should be both what?
Complete and concise
means that all services required by the user should be defined
Completeness
means that requirements should not have contradictory definitions
Consistency
Requirements that are not directly concerned with the specific services delivered by the system to its users
Non-Functional Requirements
They include timing constraints, constraints on the development process, and constraints imposed by standards
Non-functional Requirements
often apply to the system as a whole, rather than individual system features or services
Non-functional requirements
Failing to meet a non-functional requirement can mean what?
the whole system is unusable
What are the types of non-functional requirements?
- Product requirements,
- organizational requirements,
- external requirements
POE
type of non-functional requirements
These requirements specify or constrain the behavior of the software.
Product Requirements
type of non-functional requirements
These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization
Organizational Requitements
type of non-functional requirements
This broad heading covers all requirements that are derived from factors external to the system and its development process
External Requirements
An official statement of what the system developers should implement
Software Requirements Specification Document
The process of writing down the user and system requirements in a requirements document
Requirements Specification
The user and system requirements should be what?
clear, unambiguous, easy to understand, complete, and consistent
CUECC
What should you not do when writing user requirements?
You should not use software jargon, structured notations, or formal notations. You should simply describe the external behavior of the system and its operational constraints
Invent a standard format and ensure that all requirement definitions adhere to that format
Natural Language Requirements Specification Guidelines
How should you pick out key parts of the requirement?
text highlighting (bold, italic, or color)
How should you write mandatory and desireable requirements?
Mandatory requirements are requirements that the system must support and are usually written using ‘shall’
Desirable requirements are not essential and are written using ‘should’
What is The Requirements Engineering Process?
- Feasibility study
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation
- Requirements management
FESVM or FRRRR
an iterative process that can be represented as a spiral of activities
Requirements elicitation and analysis
What are the activities in Requirements elicitation and analysis?
— requirements discovery, requirements classification and organization,
requirements negotiation,
and requirements documentation
DCND
Requirements elicitation and analysis
This is the process of interacting with stakeholders of the system to discover their requirements
Requirements discovery
Requirements elicitation and analysis
Domain requirements from stakeholders and documentation are also discovered during this activity
Requirements discovery
Requirements elicitation and analysis
This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters
Requirements classification and organization
Requirements elicitation and analysis
This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation
Requirements prioritization and negotiation
Requirements elicitation and analysis
Usually, stakeholders have to meet to resolve differences and agree on compromise requirements
Requirements prioritization and negotiation
Requirements elicitation and analysis
The requirements are documented and input into the next round of the spiral
Requirements specification
Requirements elicitation and analysis
Formal or informal requirements documents may be produced
Requirements specification
The process of checking the requirements for validity, consistency, completeness, realism, and verifiability
Requirements validation
It is the process of checking that requirements actually define the system that the customer really wants
Requirements validation
It overlaps with analysis as it is concerned with finding problems with the requirements
Requirements validation
Why is Requirements validation important?
is important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service
What are the different types of checks used in requirements validation?
- Validity Checks
- Consistency Checks
- Completeness checks
- Realism Checks
- Verifiability
VCCRV
Requirements validation
A user may think that a system is needed to perform certain functions. However, further thought and analysis may identify additional or different functions that are required. Systems have diverse stakeholders with different needs and any set of requirements is inevitably a compromise across the stakeholder community
Validity checks
Requirements Validation
Requirements in the document should not conflict
Consistency Checks
Requirements Validation
There should not be contradictory constraints or different descriptions of the same system function
Consistency checks
Requirements Validation
The requirements document should include requirements that define all functions and the constraints intended by the system user
Completeness checks
Requirement Validation
Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented
Realism Checks
Requirements Validation
These checks should also take account of the budget and schedule for the system development
Realism Checks
Requirements validation
To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable
Verifiability
Requirements Validation
This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement
Verifiability
Business, organizational, and technical changes inevitably lead to changes to the requirements for a software system
Requirements management
Requirements management is the process of understanding, managing and controlling changes to system requirements
Requirements management
What are the several reasons why change is inevitable?
-
The business and technical environment of the system always changes after installation
- New hardware may be introduced, it may be necessary to interface the system with other systems, business priorities may change (with consequent changes in the system support required), and new legislation and regulations may be introduced that the system must necessarily abide by - **The people who pay for a system and the users of that system are rarely the same people
System customers impose requirements because of organizational and budgetary constraints **
- These may conflict with end-user requirements and, after delivery, new features may have to be added for user support if the system is to meet its goals - **Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory **
- The final system requirements are inevitably a compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed
When should you apply Requiremnts Change Management?
Requirements change management should be applied to all proposed changes to a system’s requirements after the requirements document has been approved
Why is Requirements Change Management essential?
Change management is essential because you need to decide if the benefits of implementing new requirements are justified by the costs of implementation
What are the stages of Requirements Change Management?
- Problem Analysis and Change Specification
- Change Analysis and Costing
- Change Implementation
PCC
Principal stages of Requirements change management
The process starts with an identified requirements problem or, sometimes, with a specific change proposal
Problem analysis and change specification
Principal stages of Requirements change management
During this stage, the problem or the change proposal is analyzed to check that it is valid
Problem analysis and change specification
Principal stages of Requirements change management
This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request
Problem analysis and change specification
Principal stages of Requirements change management
The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements
Change analysis and costing
Principal stages of Requirements change management
The cost of making the change is estimated both in terms of modifications to the requirements document and, if appropriate, to the system design and implementation
Change analysis and costing
Principal stages of Requirements change management
Once this analysis is completed, a decision is made whether or not to proceed with the requirements change
Change analysis and costing
Principal stages of Requirements change management
The requirements document and, where necessary, the system design and implementation, are modified
Change implementation
Principal stages of Requirements change management
You should organize the requirements document so that you can make changes to it without extensive rewriting or reorganization
Change implementation
As with programs, changeability in documents is achieved by minimizing external references and making the document sections as modular as possible
Change implementation
