Download Requirements Engineering - Lecture Slides | CS 230 and more Study notes Software Engineering in PDF only on Docsity!
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 1
REQUIREMENTS
ENGINEERING
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 2
Requirement Definition & Specification
• Requirements definition - Abstract description of
the services which the system should provide and
the constraints under which the system must
operate; Should be written in such a way that it is
understandable by customers without knowledge of
specialized notations
• Requirements specification – Structured document
which sets out the system service in detail; Should
be precise
• Software specification – adds further details to
specification
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 3
Requirement Definition & Specification (contd)
• Functional requirements - WHAT the system is
supposed to do
• Non-functional requirements
- Performance – the speed, response time, recovery time
- Design constraints imposed on an implementation – required standards in effect, implementation language, policies for data base integrity, resource limits, operating environments
- Attributes – considerations of portability, reliability, availability, maintainability, security, etc
- External interfaces – interactions with people, hardware, other software and other hardware
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 4
Requirement Definition & Specification (contd)
- Requirements should not contain design and
implementation details (HOW)
- Requirements writers should clearly distinguish
between identifying required design constraints and
projecting a design
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 5
Requirements Engineering
- Requirements elicitation process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand their requirements
- Requirements analysis and negotiation process of reasoning about the requirements that have been elicited; examining requirements for conflicts or inconsistencies, combining related requirements, and identifying missing requirements
- Requirements specification process of recording the requirements in one or more forms, including natural language and formal, symbolic, or graphical representations; Also, the product – document produced by the process
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 6
Requirements Engineering
- System modeling process of evaluating system’s components in relationship to one another to determine how requirements fit into the system
- Requirements validation process of confirming with the customer or user that the specified requirements are valid, correct, and complete
- Requirements Management set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the process proceeds
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 10
Requirements Elicitation Process (contd)
Participants
- Software requirements engineer
- Documentation specialists
- Potential users
No one person knows everything about what a
software system should do
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 11
Requirements Elicitation Process (contd)
Customer Bank staff
Account holder
Foreign customer Teller^ Manager Engineer
ATM system users
Withdraw cash Transfer funds Deposit funds Account balance
Withdraw cash Run diagnostics Add cash Add paper Send message
Usage statistics Security
Hardware/ Software maintenance
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 12
Requirements Elicitation
- Requirements elicitation process
- Terminology
- General procedure
- Participants
- Outcomes of good & poor elicitation processes
- Difficulties of requirements elicitation
- Different elicitation techniques
- Prototyping
- Interviewing
- Brainstorming
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 13
Outcomes of a Good Process
- Help buyers or users to understand
- their requirements, especially in the separation of what they WANT and what they NEED
- constraints imposed by the technology, organizational practices, or government regulations
- alternatives, both technological and procedural
- tradeoffs to be made
- Buyers and users
- are satisfied with the process
- feel informed and educated
- believe their risk is minimized
- are committed to the success of the project
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 14
Outcomes of a Good Process (contd)
- Software developers
- are solving the right problem for the users
- are confident that a problem is feasible
- are confident that the system will not have undesirable side effects
- have trust and confidence of the customers
- know that the customers will cooperate if the clarifications are needed during development
- have gained knowledge of the domain of the system
- have variety of information about the system that will be useful later
- feel that the system is not overly specified and that they have freedom to make implementation decisions
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 15
Outcomes of a Poor Process
- Developers are solving the wrong problem
- Buyers and users are dissatisfied
- Chaotic development process
- Missing important requirements
- Wrong decisions or tradeoffs
- Requirements will change more often o greater configuration management o wasted effort in design and implementation
- Cost and schedule overruns
- Failed or canceled projects
- Loss of money, loss of reputation or credibility,
decline in the developers’ morale
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 19
Communication Barriers
- Users and developers have different professional
vocabularies
- Users have different concerns from developers
- User – high level attributes (usability & reliability)
- Developer – low level technical issues (resource utilization, algorithms, hardware/software tradeoffs)
- Problems exist with each form or medium of
communications
- Natural languages, diagrams, charts, pictures, specification languages
- People involved in requirements elicitation are all
different
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 20
Knowledge and Cognitive Limitations
- Requirements elicitor must have adequate domain
knowledge
- Developers should not make domain tradeoffs
- Users should not make technical tradeoffs
- No person have perfect memory; oral and written
information may be misinterpreted
- Informal or intuitive quantitative information are
frequently interpreted differently by different people
- People have difficulties with scale and complexity
- People tend to state the problem in terms of the
favored solution
- Some people develop “tunnel vision”
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 21
Human Behavior Issues
- Conflicts and ambiguities
- “It is other user’s responsibility to tell the developers”
- “User is a domain expert and will give all the needed domain information”
- “Developer will ask appropriate questions to get the domain information”
- Expectation or fear that installation of software will
necessitate all kinds of changes in behavior,
including the potential loss of jobs
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 22
Technical Issues
- Problems are becoming increasingly complex
- Requirements change over time
- Software and hardware technologies are changing
rapidly
- Nature of the system often imposes constraints
- Novel systems require much more substantial requirements elicitation effort
- Requirement elicitation for one-of-a-kind system build for specific customer assume that the customer is the ultimate authority
- Requirements elicitation for COTS software depends on market research, examination of competing products, and communication with a sample of typical users
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 23
Requirements Elicitation Techniques
Broad, generic categories
Asking – identify appropriate person; ask what the
requirements are
Observing and inferring – observe the behavior of the
users of an existing system; infer their needs from that behavior
Discussing and formulating – discuss and jointly
formulate with the users a common understanding of the requirements
Negotiating with respect to a standard set – negotiate
with the users which of the features will be included, excluded, or modified
Copyright © K.Goseva 2006 CS 230 Introduction to Software Engineering Slide 24
Requirements Elicitation Techniques
Broad, generic categories (contd)
Studying and identifying problems – slow system may
require complex performance monitoring to identify the requirements to change the system
Discovering through creative processes – for very
complex systems with no obvious solutions
Postulating – when there is no access to the user or for the
novel product, use creative processes and intuition to identify features that the user might want
No one technique is sufficient for realistic projects
