requirement engineering!
Post on 12-Dec-2015
35 Views
Preview:
DESCRIPTION
TRANSCRIPT
Requirement Engineering
by
Dr. Rizwan
Requirement
The hardest single part of building a software system is deciding what to build….
No other part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.
F.P Brooks
Requirement Software Requirement stimulates what must be
Accomplished, Transformed, Produced or Provided
Additionally, a Software Requirement is a software capability that must be met or possessed by a software component in order to satisfy a contract, standard, or specification
The source of these Requirements could come from Client/Customer Buyers, Users/End user, or system specifications
Requirement Engineering
The description of the services and constraints are the requirements for the system and
The process of Finding out, Analyzing, Documenting and Checking these services and Constraints are called
Requirements Engineering.”
Ian Sommerville
Requirement Engineering
A process in which “what is to be done” is
Elicited Modeled and Communicated Freeman
Why are requirements important? The requirements are how we communicate They are the only part that everyone understand
CUSTOMER
USER DEVELOPER
Requirements
How are Programs Usually Written …
The requirements specification was defined like this
The developers understood it in
that way
This is how the problem is solved now
That is the program after debugging
This is how the program is described by marketing
department This, in fact, is what the customer wanted … ;-)
Why are requirements important? Inconsistent and incomplete requirements are the
most frequent causes of the system problems
10% 20%
Incomplete requirements
Lack of user involvement
Lack of resources
Unrealistic expectations
Lack of executive support
Changing requirements
Lack of planning
System no more needed
Causes of the failed projects
Requirement Types
Needs The capabilities and characteristics required in
the software system to solve the problem.
Wishes/Wants The capabilities and characteristics of the
software system desired by the users.
Expectations The capabilities and characteristics of the
software system expected by the users.
Software Requirement Specification Document
SRS (Software Requirement specification) The official statement of what is required by the
system developers The goal of the SRS is to describe all externally
observed behaviors and characteristics expected of the software system
Includes user requirements and system requirements Standards for SRS
RUP IEEE Ian Summerville
Characteristics of SRS
Correct All requirements stated in the SRS are one that the
software shall meet.
Unambiguous Every requirement stated in the SRS only has one
logical interpretation.
Complete The SRS includes all significant requirements The SRS includes all realizable classes of input data The SRS includes full labels and references to all
figures, tables and diagrams.
Characteristics of SRS
Verifiable For every requirement stated in the SRS, there exists
some finite cost-effective process with which a person or machine can check that the software meets the requirements.
Modifiable The entire SRS has a style and structure such that
any changes to the requirements can be made Easily, Completely, and Consistently and retaining the structure and style.
Characteristics of SRS
Consistent No subset of individual requirements stated in the SRS
conflict with other individual requirements.
Traceable For every requirement stated in the SRS, it is clear of
the requirements origin and it is possible to reference each requirement in future developments.
Advantages of SRS
The SRS can establish the basis for contractual agreement between the customer and developers.
The SRS can establish the basis for performing cost, schedule, and resource estimates for the developmental effort.
The SRS can provide a baseline for verification and validation of the software.
Types of SRS
Production of System Specification Written document Graphical model Formal mathematical model Usage scenarios Prototype Any combination of above
IEEE Standard
Introduction Purpose of the requirement document Scope of the product
Definitions, acronyms, and abbreviations
References
Why Engineer Requirement
Wicked problems Most large software systems address wicked
problems Problems which are so complex that they can never
be fully understood and where understanding evolves during the system development
Therefore, requirements are normally both incomplete and inconsistent
Requirement Types
Functional Requirements The functional requirements define the fundamental actions
that the software must perform. The actions describes accepting inputs, processing, and
generating the outputs.
Behavioral Requirements The behavioral requirements define the actions taken when
the software responds to internal and external stimulus. This includes describing what event causes an activity to
start up and the event that causes it to stop.
Requirement Types
Performance Requirements The performance requirements specify the numeric
requirements that are placed of the software as well as on the human interaction with the software.
Examples of performance requirements may include: Number of data transactions with in a certain time frame Number of simultaneous users Number of terminals to be supported
Requirement Types
Operational Requirements Are usability of the software as it communicates with its
human users. This may include information concerning the
Qualifications of the users, Level of detail for external messages, and Graphical User Interface standards.
The constraint requirements Define any restrictions that will impact the software that is
being developed.
Requirement Types
The constraint requirements Constraint requirements deal with:
Design/Development restrictions. Example: Target hardware and programming
language. Environment Restrictions.
Example: Software size and resource utilization. Data Restrictions.
Example: Maximum number of files and size of files.
Requirement Engineering Process
Requirement Engineering All activities devoted to
Identification of user requirements, Analysis of the requirements to drive additional
requirements, Documentation of the requirements as a specification Validation of the documented requirements against
user needs, as well as processes that support these activities.
Requirement Engineering Process
Software Requirement Elicitation The process through which the customers, buyers
or the users of software system discover, reveal, articulate and understanding their requirements
Software Requirements Elicitation is any activity that has as its objectives to:
Gather, Determine, Extract, or expose software requirements
Requirement Engineering Process
Software Requirement Analysis The process of reasoning about the requirements that
have been elicited . Involves examining requirements for conflicts or
inconsistencies, combining related requirements, and identifying missing requirements
Software Requirements Analysis is any activity that has as its objective to
Organize, Interpret, Understand, Classify, or assess feasibility, Completeness, or consistency of software requirements.
Requirement Engineering Process
Software Requirement Specification The process of recording the requirements in one or more
forms, including natural language and formal, symbolic, or graphical representations
Software Requirements Specification is any activity that has as its objective to capture a description of the software requirements
Usually the final form of this description is a software requirements specification (SRS).
Software Requirement Validation The process of confirming with the customer or user of the
software that the specified requirements are valid, correct, and complete
Software Requirements Validation is any activity that has as its objective to obtain buyer approval of the specification of the software requirements.
Requirement Engineering Process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Requirement Engineering Process
In reality these processes cannot be performed sequentially
All process are intertwined and performed repeatedly Elicitation is not universally accepted
Identifying
Gathering
Determining
Formulating
Extracting
Exposing
Outcomes of Requirement Elicitation
TangibleIntangible
Outcome of a Good Elicitation Process
Users Perspective The users will have a better understanding of their needs and
constraints. The users will be in a position to evaluate alternatives and
understand the implications of their decisions. This level of understanding is extremely important since it is
usually the users who drives the requirements, which in turn drives the design and implementation of the entire software system.
Thus, the quality of the requirements document is related to the users understanding of the issues and tradeoffs involved.
Outcome of a Good Elicitation Process
Users Perspective The users and the developers form a common vision of
the problem and the conceptualized software solution. To strive for this common understanding of all
individuals involved in the software engineering process
A sense of ownership Feel informed and educated Committed to the success of the project
Outcome of a Good Elicitation Process
Developers Perspective This is the fundamental process that will be used
to construct a clear high level specification of the problem that is to be solved.
Other outcomes of a good elicitation process are developers who:
Are developing a solution to the right problem Are solving a problem that is feasible from all
perspectives Have a high level specification of the solution Have cooperative users
Outcome of a Good Elicitation Process
Developers Perspective Have all the necessary information, explanations, and
justifications Can make proper design justifications Need minimal ongoing interactions with the users They have trust and confidence of the customer Knowledge of the domain of the system
Difficulties in Requirement Elicitation
The process of elicitation of requirements is a difficult process. No single person has the complete picture. Work effectively as a coherent group. The following are some common difficulties associated with this
process:
Articulation Problems Expression/ Communication Articulation problems can occur because the users are usually
experts in their application domain but not in the process of engineering software.
Additionally, the engineers are experts in development and not in the users application domain.
This problem is magnified by the users and developers having different vocabulary, terms, and concepts
Difficulties in Requirement Elicitation
Articulation of the users needs The users may not be aware of their needs Users who are unwilling to prioritize and make tradeoffs The users may be aware of needs but be afraid to articulating it Users and developers misunderstand concepts or relationships User cannot make up their minds No single person has complete picture Developers may not really be listening to the users
Difficulties in Requirement Elicitation
Articulation of the users needs Developer may fail to understand, appreciate, or relate to the
users Developers who are not skilled in listening Developers who are dominating in their approach to
elicitation Developers who are solution not problem orientated
Difficulties in Requirement Elicitation
Communication Barriers Communication is not a single direction information flow Users and developers come from different worlds and have
different professional vocabularies The users have different concerns from those of developers Medium of communication-Natural language are inherently
ambiguous People involved are different-some are submissive, some
are assertive
There are different value system among people
Difficulties in Requirement Elicitation
Problem Complexity The complexity of modern software system makes the
process of requirements elicitation extremely difficult. These systems have interconnections between subsystems
and environments that even expert in specialized disciplines have difficulty understanding.
Nature of Requirements Requirements change and migrate Users learn and grow Requirements are diverse and conflicting Multiple views can be difficult to integrate Requirements can be difficult to evaluate.
Difficulties in Requirement Elicitation
Knowledge and Cognitive Limitations Tunnel vision User and Developers don’t have adequate domain
knowledge No person has perfect memory Interpretation of statistics Problem simplification and ignoring part of the problem
because of complexity Some people are uncomfortable or impatient with
exploration
Human Behavioral Issues Elicitation is a social process Everyone (users) assumes that it is not his/her responsibility to
tell the developers Developer may assume that user will give the information
User may assume that developer will ask appropriate questions
Expectation and /or fears from proposed system
Technical Issues Obsolete requirement by the time the elicitation process is
completed Software and hardware technologies (corporate management,
government regulations, sales and marketing department)
Unprecedented system
Difficulties in Requirement Elicitation
Requirement Elicitation Techniques
Joint Application Development (JAD) Quality Function Deployment (QFD) Adaptive Loops Framework Prototyping Contextual Inquiry Critical Success Factors Analysis Brainstorming Interviewing PIECES framework
Performance information and data, Economy
Control, Efficiency, and services
Key Points
Requirements set out what the system should do and define constraints on its operation and implementation.
Functional requirements set out services the system should provide.
Non-functional requirements constrain the system being developed or the development process.
User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.
System requirements are intended to communicate the functions that the system should provide.
It is very difficult to formulate a complete and consistent requirements specification
Volatile requirements are dependent on the context of use of the system
Key Points
A software requirements document is an agreed statement of the system requirements.
The IEEE standard is a useful starting point for defining more detailed specific requirements standards.
A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader
The requirements document is a description for customers and developers
Requirements errors are usually very expensive to correct after system delivery
Reviews involving client and contractor staff are used to validate the system requirements
top related