requirement engineering in s/w engineering
TRANSCRIPT
What are system requirements?• Requirements are defined during the early stages of a
system development as a specification of what should be implemented or as a constraint of some kind on the system.
• They may be:– a user-level facility description, – a detailed specification of expected system behaviour,– a general system property, – a specific constraint on the system,– information on how to carry out some computation,– a constraint on the development of the system.
What is requirements engineering?• Requirements engineering covers all of the activities
involved in discovering, documenting, and maintaining
a set of requirements for a computer-based system.
• The use of the term ‘engineering’ implies that
systematic and repeatable techniques should be used
to ensure that system requirements are complete,
consistent, relevant, etc.
What happens if the requirements are wrong? The system may be delivered late and cost
more than originally expected.
The customer and end-users are not satisfied
with the system. They may not use its facilities
or may even decide to scrap it altogether.
The system may be unreliable in use with
regular system errors and crashes disrupting
normal operation.
If the system continues in use, the costs of
maintaining and evolving the system are very
high.
Why is RE difficult?• Changing environments
– Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing.
• Differing views– Multiple stakeholders with different goals and priorities are
involved in the requirements engineering process.• Unclear opinions
– System stakeholders do not have clear ideas about the system support that they need.
• Politics and people– Requirements are often influenced by political and
organisational factors that stakeholders will not admit to publicly.
Requirements engineering Terminology
Terms that you should understandStakeholders
Viewpoints
concerns
Stakeholders• People or roles who are affected, in some way,
by a system and so who can contribute requirements or knowledge to help you understand the requirements
• Example – medical system stakeholders– Doctors– Nurses– Patients– Hospital managers– Administrators – Owners of other connected systems
Viewpoints• Viewpoints are a way of organizing and
grouping requirements that have been elicited from stakeholders
• The requirements generally represent the views and needs of a class or type of stakeholder
• Examples of viewpoints– End-user viewpoint– Managerial viewpoint– System administration viewpoint– Engineering viewpoint
Concerns• Are issues that an organization must pay
attention to and that are systemic i.e. they apply to the system as a whole
• They are cross-cutting issues that may affect all system stakeholders and the requirements from these stakeholders
• Concerns help bridge the gap between organizational goals (what the organization has to achieve) and system requirements (how a system contributes to these goals)
Concerns
Software and hardware
Operators and managers
Society
The organization
SafetyAvailabilitySecurity
Requirements engineering processes
Different views of the processes involved in requirements engineering
Requirements engineering problems
Fundamental issues that mean that establishing requirements for complex systems will always be a difficult technical and organisational problem
Requirements change
• System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also changeTechnology changesOrganisational changesMarket changesEconomic changesPolitical and legal changes
• It is often difficult to understand the implications of changes for the requirements as a whole
Stakeholder perspectives
The problem and the required system
Social perspectiveTechnical perspective
ObjectsFunctionsRoles ...
User perspectiveInteractionsUsability Management perspective
Certificationperspective
Customerperspective
Stakeholder uncertainty
• Key stakeholders have other jobs to do!– Developing detailed requirements for future systems often
cannot be given a high priority by the senior people who will be affected by these requirements.
– They therefore are unable to express their requirements except as vague, high-level descriptions
The requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Feasibility studies
• A feasibility study decides whether or not the proposed system is worthwhile.
• A short focused study that checks– If the system contributes to organisational
objectives;– If the system can be engineered using current
technology and within budget;– If the system can be integrated with other systems
that are used.
Feasibility study implementation
• Based on information assessment (what is required), information collection and report writing.
• Questions for people in the organisation– What if the system wasn’t implemented?– What are current process problems?– How will the proposed system help?– What will be the integration problems?– Is new technology needed? What skills?– What facilities must be supported by the proposed
system?
Understanding Requirements• Collecting needs from the customer.• Managing the Process.• Tasks involved:
InceptionElicitationElaborationNegotiationSpecificationValidationRequirements Management
• During inception, the requirements asks a set of questions to establish:– Basic understanding of the
problem.– Nature of the solution that is
desired.• Requirements Engineers needs to
Identify the stakeholders, recognize multiple viewpoints, work toward collaboration and initiate the communication.
Inception (Beginning)
Eliciting requirements is difficult because of Problems of scope identify the boundaries of the system. Problems of understanding domain , computing
environment. Problems of Volatility requirements may change over time. Elicitation may be accomplished through two activities:
Collaborative Requirements GatheringQuality Function Deployment.
Elicitation: (Extraction)
• Takes the information obtained during
inception and elicitation.
• Focuses on developing a refined model
of software functions, features &
Constraints.
• This is an analyzing phase.
• It defines the functional, informational
and behavioral constraints of the
problem domain.
Elaboration (explanation)
Software engineer reconciles the
conflicts between what the
customer wants and what can be
achieved.
Requirements are ranked by the
customer, users and other
stakeholders.
Risks associated with each
requirement are identified.
Negotiation (Cooperation)
Final work product produced by the requirements engineer.
Form of SRS.Serves as a foundation.It formalizes the functional and
behavioral requirements of the proposed software in both the graphical and textual format.
Specifications
Specification is examined to ensure that all the sw requirements have been stated unambiguously.
Errors have been detected and corrected.
Members involved:Software EngineersCustomersUsersOther stakeholders.
Validation
Requirements checking
• Validity. Does the system provide the functions which best
support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer
included?
• Realism. Can the requirements be implemented given available
budget and technology
• Verifiability. Can the requirements be checked?
Project team performs a set of activities to identify, control and track
requirements and changes to the requirements at any times as the project
proceeds.
Each requirement is assigned a unique identifier.
Place the requirements into one or traceability tables.
Tables may be stored in a database that relate features, sources,
dependencies subsystems and interfaces to the requirements.
Requirements Management