Escolar Documentos
Profissional Documentos
Cultura Documentos
Objectives
To describe the principal requirements engineering
activities and their relationships To introduce techniques for requirements elicitation and analysis To describe requirements validation and the role of requirements reviews To discuss the role of requirements management in support of other requirements engineering processes
What is a requirement?
It is about WHAT not HOW Requirements are the descriptions of the services provided by a system and its operational constraints It may range from a high level abstract statement to a detailed mathematical specification It may be as complex as a 500 pages of description It may serve as the basis for a bid for a contract or the basis for the contract itself
Why requirements?
What are the advantages of a complete set of documented requirements?
Ensures the user (not the developer) drives system
functionalities Helps avoiding confusion and arguments Helps minimizing the changes
Why requirements?
2/3 of finished system errors are requirements and design errors A careful requirements process doesnt mean there will be no changes later
Average project experiences about 25% changes in the
requirements This accounts for 70-80% if the rework of the project Important to plan for requirements changes
knowledge.
understand the business problem you are trying to solve, not specifically what the system will do (i.e. functional requirements) but what the business wants to achieve through a system.
requirements Services and constraints of the system In natural language or diagrams Readable by everybody Serve business objectives
System requirements
Services and constraints of the system in detail Useful for the design and development Precise and cover all cases Structured presentation
Example
User requirement: The library system should provide
a way to allow a patron to borrow a book from the library. System requirement: The library system should provide a withdraw interaction that allows a patron to withdraw a book given the isbn and copy number of the book to be withdrawn. The interaction fails if: the book is already withdrawn, the book is not in the library's collection, the patron has already withdrawn 5 books, the patron owes more than $5, the book is on hold by someone else.
Types of requirements
Functional requirements
Services the system should provide
What the system should do or not in reaction to particular situations
Non-functional requirements
Constraints on the services or functions offered by the system
process (CASE, language, development method), standards etc Domain requirements From the application domain of the system May be functional or non-functional Examples: Medicine, library, physics, chemistry Note: You can have user/system functional/non-functional requirements.
Non-functional requirements
It is important to be able to test/verify/check non-
functional requirements
Prope rty Sp eed Size Ease o f use Reliability Mea sure Processed transaction s/seco nd User/Ev en t resp onse time Screen refresh t ime K Byt es Number of RAM ch ip s Training t ime Number of help frames Mean time t o failure Probabilit y of unavailability Rate o f failure o ccurren ce Availabilit y Time to restart after failure Percent age of events causin g failure Probabilit y of dat a co rrup tion on failure Percent age of t arget dependent statemen ts Number of t arget sy st ems
documenting and validating the requirements of the system. Each software development process goes through the phase of requirements engineering. requirements engineering bridges the gap between an initial vague recognition that there is some problem to which we can apply computer technology, and the task of building a system to address the problem.
Requirement engineering
5 important activities: Feasibility study Requirements elicitation and analysis Requirements documentation Requirements validation Requirements management
Requirement engineering
Feasibility study Requirements elicitation and analysis Requir ements specification Requirements validation System models User and system requirements Requirements document Feasibility report
Feasibility study
It is done at first to decide whether or not the project
legal
Should make you aware of the risks Is there any thing a software do in the problem under
consideration?
Feasibility study
Doing the study Consult information sources: managers, software engineers, end users Based on information collection (interviews, surveys, questionnaires) Should be short (2-3 weeks)
information collection and report writing. Questions for people in the organisation
What if the system wasnt implemented?
discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the systems operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
Domain understanding
Process entry Requirements collection
Prioritization
Requirements document
Conflict resolution
Classification
system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.
Requirements discovery
The process of gathering information about the
proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems.
Interviewing
In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that they use and the system to be developed. There are two types of interview
Closed interviews where a pre-defined set of questions
are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
Interviews in practice
Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of
what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements
Requirements engineers cannot understand specific domain
terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isnt worth articulating.
Effective interviewers
Interviewers should be open-minded, willing to listen
to stakeholders and should not have pre-conceived ideas about the requirements. They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as what do you want.
Scenarios
Scenarios are real-life examples of how a system can
Requirements validation
Concerned with demonstrating that the requirements
define the system that the customer really wants. Requirements error costs are high so validation is very important
Fixing a requirements error after delivery may cost up to
Requirements checking
Validity. Does the system provide the functions which best
support the customers 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?
Requirements reviews
requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.
Review checks
Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly
understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements?
Requirements management
Requirements management is the process of managing
changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory.
Requirements change
The priority of requirements from different viewpoints
changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development.
Requirements evolution
from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy
plan:
Requirements identification
How requirements are individually identified? The process followed when analysing a requirements change. The amount of information about requirements relationships that is maintained.
Traceability policies
Traceability
Traceability is concerned with the relationships between
requirements;
Requirements traceability
Links between dependent requirements;
Design traceability
Links from the requirements to the design;
A traceability matrix
Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 1.2 D R R R D R R 1.3 R D R D D D 2.1 2.2 2.3 D 3.1 3.2 D
Change management
The process of change management is a workflow process whose
stages can be defined and information flow between these stages partially automated.
Traceability management
Automated retrieval of the links between requirements.
propose change. Change analysis and costing- Assess effects of change on other requirements. Change implementation- Modify requirements document and other documents to reflect change.
Change management
Conclusion
Requirements collection is the primary step in the
software engineering process and any error in this may lead to the development of a software solution to a wrong problem. There is no definite process for requirements engineering, it depends on the problem domain. The analyst should make the best effort to identify the requirements correctly by making use of the several different approaches together.
Conclusion
Each project is different, which is why there are no
hard and fast rules. The best thing you can do is be self-aware of what you know and what you hope to discover with each action you take, whether its defining the business requirements, shopping for the solution, or evaluating a specific tool.
Conclusion
Make no assumptions. Even if you came from the line
of business, ask the questions you think you know the answers to. Be optimistic about getting the RE process right.
Conclusion
Doing requirements engineering correctly requires an
interdisciplinary approach that considers the needs of multiple stakeholder groups. It also requires expertise in the various skills of requirements engineering including requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management.
Conclusion
Requirements development is an iterative process. One
should not expect to go through the steps in a one-shot, linear fashion. For example, the requirements analysts may talk to a user, then analyze what the user had to say. They may go back to that user for clarification and then document what they understand as that part of the requirements.
said, but what you dont understand is what I said is not what I mean
Questions?