Introduction To

Software Engineering
LECTURER: SYED HASNAIN ABBAS BUKHARI
Outcome  of  a  Good  Elicita0on  Process  
q Users Perspective
q The users will have a better understanding of their needs and
constraints.
q The users will be in a position to evaluate alternatives and
understand the implications of their decisions.
q 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.
q Thus, the quality of the requirements document is related to the
users understanding of the issues and tradeoffs involved.

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Outcome  of  a  Good  Elicita0on  Process
q Users  Perspec0ve  

q The   users   and   the   developers   form   a   common   vision   of   the   problem  

and  the  conceptualized  so<ware  solu>on.    

q To   strive   for   this   common   understanding   of   all   individuals   involved   in  

the  so<ware  engineering  process.  

q A  sense  of  ownership.  

q Feel  informed  and  educated.  

q CommiCed  to  the  success  of  the  project.  

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Difficulties in Requirement
Elicitation
Difficulties in Requirement Elicitation
q Articulation of the users needs

q The users may not be aware of their needs.

q Users who are unwilling to prioritize and make tradeoffs.

q The users may be aware of needs but be afraid to articulating it.

q Users and developers misunderstand concepts or relationships.

q User cannot make up their minds.

q No single person has complete picture.

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Difficulties in Requirement Elicitation
q Articulation of the users needs (developers point of view)

q Developers may not really be listening to the users.

q Developer may fail to understand, appreciate, or relate to the users.

q Developers who are not skilled in listening.

q Developers who are dominating in their approach to elicitation.

q Developers who are solution not problem orientated.

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Difficulties in Requirement Elicitation
q Communication Barriers
q Communication is not a single direction information flow.

q Users and developers come from different worlds and have

different professional vocabularies.
q The users have different concerns from those of developers.

q Medium of communication-Natural language are inherently

ambiguous.

q People involved are different, some are submissive, some are

assertive.

q There are different value system among people.

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Difficulties in Requirement Elicitation
q Problem Complexity
q The complexity of modern software system makes the process of
requirements elicitation extremely difficult.
q These systems have interconnections between subsystems and
environments that even expert in specialized disciplines have difficulty
in understanding.

q Nature of Requirements
q Requirements change and migrate.
q Users learn and grow.
q Requirements are diverse and conflicting.
q Multiple views can be difficult to integrate.
q Requirements can be difficult to evaluate.
S y e d   H a s n a i n   A b b a s   B u k h a r i  
Difficulties in Requirement Elicitation
q Knowledge and Cognitive Limitations
q Tunnel vision.
q User and Developers don’t have adequate domain
knowledge.
q No person has perfect memory.
q Interpretation of statistics.
q Problem simplification and ignoring part of the problem
because of complexity.
q Some people are uncomfortable or impatient with
exploration.

S y e d   H a s n a i n   A b b a s   B u k h a r i  

Difficulties in Requirement Elicitation
q Human Behavioral Issues
q Elicitation is a social process.
q Everyone (users) assumes that it is not his/her responsibility to tell the
developers.
q Developer may assume that user will give the information.
q User may assume that developer will ask appropriate questions.
q Expectation and /or fears from proposed system.

q Technical Issues
q Obsolete requirement by the time the elicitation process is completed.
q Software and hardware technologies (corporate management,
government regulations, sales and marketing department).
q Unprecedented system.
S y e d   H a s n a i n   A b b a s   B u k h a r i  
Requirement Elicitation Techniques
q Joint Application Development (JAD)
q Quality Function Deployment (QFD)
q Adaptive Loops Framework
q Prototyping
q Contextual Inquiry
q Critical Success Factors Analysis
q Brainstorming
q Interviewing
q PIECES framework
q Performance information and data, Economy
q Control, Efficiency, and services
S y e d   H a s n a i n   A b b a s   B u k h a r i  
Key Points
q Requirements set out what the system should do and define constraints on
its operation and implementation.

q Functional requirements set out services the system should provide.

q Non-functional requirements constrain the system being developed or the

development process.

q User requirements are high-level statements of what the system should do.
User requirements should be written using natural language, tables and
diagrams.

q System requirements are intended to communicate the functions that the

system should provide.
q It is very difficult to formulate a complete and consistent requirements
specification.

q Volatile requirements are dependent on the context of use of the system.

S y e d   H a s n a i n   A b b a s   B u k h a r i  
Key Points
q A software requirements document is an agreed statement of the
system requirements.
q The IEEE standard is a useful starting point for defining more detailed
specific requirements standards.
q A requirements definition, a requirements specification and a software
specification are ways of specifying software for different types of
reader.
q The requirements document is a description for customers and
developers.
q Requirements errors are usually very expensive to correct after
system delivery.
q Reviews involving client and contractor staff are used to validate the
system requirements.

S y e d   H a s n a i n   A b b a s   B u k h a r i