F05 SENG 411 L5

From Craig

"I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!" -- George Romney, 1967 U.S. Presidential Candidate

The most difficult part of software development

• Deciding what to build

Getting it wrong cripples your development effort

• Schedule overruns
• Missing scope

Iterative extraction and refinement of requirements

• Customers don't know what they want
• Customers don't know what questions must be answered
• They have not thought the problem through in detail
• Extensive iteration between customer and client.

Businesses as a hive

• As a business gets large enough, there is no single person who knows how everything (ie. business processes) works.
• Eliciting requirements for a business process will required coordination efforts between several people. May not be possible to get everyone in the same room at the same time.

Hives (Swarms)

• Adaptable
  • New Stimuli
• Evolvable
  • Shifting locus of adaption
• Resilient
  • Redundancy
• Boundless
  • Non linear. Can build upon itself
• Novelty
  • "Sensitive to preconditions". ie. size of the effect is not proportional to the size of the cause
  • Interlinked individuals provide exponential combinations
  • Individual variations can be allowed.

Apparent Disadvantages of Swarm systems

• Non-Optimal
  • Redundancy
• Non-controllable
  • No central authority which has direct control
• Non-predictable
  • Applying force to the structure may cause unpredictable changes in the structure
• Non-understandable
  • Too many interactions
• Non-immediate
  • Cause and effect is not immediate

Swarm information from Out of control by Kevin Kelly

Brooks states, "I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some version of the product being specified.

Analysis (Solving problems)

"The understanding of a problem evolves as the solution evolves. Developing the solution using different solution paths deepens the understanding of the problem and its solution.

It is not logically possible to understand a problem before solving the problem. An understood problem is a solved problem. The plan for solving a problem cannot be made before solving the problem. The plan evolves as the problem is solved. "

Terminology

At this point in time, there doesn't appear to be general acceptance of terminology in the literature.

Requirements Engineering - a general term which encompasses all the activities related to requirements. Typical broken down into 4 specific processes:

Strictly speaking, these processes cannot be separated and completed in a sequential fashion. The four processes are best completed iteratively.

Types of requirements

The IEEE Standard Glossary of Software Engineering defines 5 types of requirements other than functional requirements:

• Performance Requirements
• Interface Requirements
• Design Requirements
• Implementation Requirements
• Physical Requirements

The IEEE defines good software requirements as being:

• unambiguous
• complete
• verifiable
• consistent
• modifiable
• traceable
• usable during operations and maintenance

General process for eliciting requirements

For processes which gets information directly from the people who will use the system:

1. Identify relevant sources of requirements (eg. users)
2. Ask the appropriate questions to gain an understanding of their needs
3. Analyze the gathered information, looking for implications, inconsistencies, or unresolved issues
4. Confirm your understanding of the requirements with the users
5. Synthesize appropriate statements of the requirements

Several elicitation techniques have evolved from this general procedure which include: the definition of specific processes (like JAD), specific questions or categories of questions to be asked, structured meetings formats, specific individual or group behaviors, and templates for organizing and recording information.

The goal of Requirements Elicitation is the development of a set of requirements which can be used by the software development team.

It is important to note that requirements analysis is a key component to learning aspects of the problem domain which are relevant to the system. As many technical staff as possible should be involved with the process of requirements analysis. For developers which are not, there will be higher demands on the documentation produced as part of requirements engineering.

Validating Requirements

Requirements Inspection Checklist

1. All items need to specify the solution to the problem have been included
2. Each item is free of error
3. Each item is exact, there is a single interpretation, the meaning of each item is understood and the specification is easy to read
4. No item conflicts with any other item in the specification
5. Each item is pertinent to the problem and its solution
6. During program development and acceptance testing, it will be possible to determine whether the item has been satisfied
7. Each item can be traced to its origin in the problem environment
8. Each item can be implemented with the available techniques, tools, resources and personnel and within the specified cost and schedule constraints
9. The requirements specifications are a statement of the requirements that must be satisfied by the problem solution, and they are not obscured by proposed solutions to the problem
10. The requirements specifications are expressed in such a manner that each item can be changed without excessive impact on other items
11. Changes to the completed requirements specifications can be controlled, each proposed change can be traced to an existing requirement, and the impact of the proposed change can be assessed.

Problems with requirements engineering

Articulation problems

1. The users of the proposed system may be aware of their needs, but they are unable to articulate them appropriately
2. The users may not be aware of their needs
3. The users may be aware of their needs, but be afraid to articulate them
4. Users and developers misunderstand concepts or relationships because they have different meanings for common terms
5. Users don't understand the consequences of their decisions or they don't understand the alternatives
6. No single person has a complete picture
7. Developers may not really be listening to the users
8. Developers may fail to understand, appreciate, or relate to the users.
9. Developers may tend to overrule or dominate the users.

Communication barriers

1. Users and developers come from different worlds
2. Users have different concerns. They are usuall high level attributes like usability and reliability where the developer's concerns may be more focused on low level technical issues like resource usage, algorithms and hardware/software tradeoffs.
3. Natural languages are inherently ambiguous.
4. Requirements elicitation, by its nature, has significant social interaction and the people involved are all different.
5. Different personality types and different value systems among people.

Knowledge and Cognitive limitations

1. The requirements elicitor must have adequate domain knowledge. Developers should not make domain decisions and users should not make technical decisions.
2. People's memories are limited. Users or developers may not remember exactly what was said or decided. Written and oral communication are interpreted differently
3. We often try to use quantitative information and statistics to express needs and requirements
4. People can have difficulty understanding scale and complexity. As problems get larger, we deal with them in different ways
5. We often have a preconceived approach to the solution of a problem that affects our ability to state the problem clearly
6. We can become to focused to a narrow component of a problem
7. On some systems, we may need to explore a variety of solutions. This can frustrate some people

Human Behavior Issues

1. There can be conflicts and ambiguities in the roles that users and developers play in the requirements elicitation process
2. Sometimes people are intimidated or afraid to speak up
3. The development of a software system to support an organization usually results in a fear that installation of new software will necessitate changes in behavior of individuals and groups. This could include the fear of losing ones job.

Technical issues

1. Problems to be solved are becoming increasingly complex
2. Requirements change over time
3. Software and hardware technologies change rapidly
4. There are many sources of requirements
5. The nature or novelty of the system often imposes constraints on the elicitation process.

Categorization of Requirements Elicitation Techniques

• Asking: Identify the appropriate person and ask them what the requirements are
• Observing and inferring: Observe the behavior of users of an existing system or set of processes and then infer their needs from their behavior
• Discussing and formulating: Discuss with users their needs and jointly formulate a common understanding of the requirements
• Negotiating with respect to a standard set: Beginning with an existing or standard set of requirements or features, negotiate with users which of those features will be included, excluded or modified.
• Studying and identifying problems: Typically used with large systems. Perform an investigation of problems to identify requirements.
• Discovery through creative processes: For complex problems with no obvious solutions, employ creative processes involving developers and users.
• Postulation: When no user is available, identify features or capabilities that the user might want (note: dangerous!)

A sampling of Requirements Elicitation Techniques

JAD (Joint Application Design)

JAD was developed in 1977 by IBM; it is a technique designed to promote cooperation, understanding and teamwork among buyers, users and developers. It is a defined process through which a shared vision of the system can be developed. Developers help users formulate problems and explore solutions and the users gain a feeling of involvement, ownership, and commitment to the success of the system.

Four main tenets of JAD

• group dynamics
• the use of visual aids to enhance communication and understanding
• organized and rational process
• "What you see is what you get" documentation philosophy

Two Major Steps of JAD

• JAD/Plan (addresses requirements elicitation)
• JAD/Design (addresses software design)

Each step consists of three phases:

• Customization
  • Preparation of tasks for the session
• Session
  • Structured and facilitated meetings
• Wrap up
  • Converting information to a form of documentation

Meetings are controlled by the session leader. The main abilities of the session leader are:

• understand and facilitate group dynamics
• initiate and focus discussions
• recognize when meetings get off track and put them back on track
• deal effectively with different personalities and behaviors of participants
• remain enthusiastic through sometimes long and difficult meetings

Each meeting has an analyst. The analyst must produce the documents for the JAD sessions. The analyst must be an experienced developer who understands the technical issues and details which are discussed during sessions.

An executive sponsor is also present at the sessions. The sponsor has 2 main responsibilities during sessions: Provide other participants with high level or strategic insight into the system being build. The second responsibility is to make executive-level decisions and commitments such as resource allocations which can affect the requirement elicitation process.

User representatives are people who will use the software being developed.

Information systems representatives are typically operations personnel who are familiar with capabilities of information systems. Their role is to help users understand what is and what is not feasible in the new system.

Specialists are persons who can provide detailed information on a narrow, well-defined topic.

JAD Session

• One or more group meetings
• Goal: Define the high-level requirements for the new system
• Goal: Define the scope of the new system.

General structure of a Session

• Conduct Orientations
• Define High-Level requirements
  • Objectives
  • Anticipated benefits
  • Strategic and Future considerations
  • Constraints and assumptions
  • Security, audit and control.
• Bound the scope of the system (triage)
• Identify and Estimate JAD/Designs
• Identify Participants for the JAD/Design step
• Schedule JAD/Design meetings
• Document any issues which have arisen from the session
• Conclusion

Brainstorming

Simple group technique for generating ideas. It allows people to suggest and explore ideas in an atmosphere free of criticism and judgement.

Brainstorming sessions consist of two phases:

• Generation
• Consolidation

Easy to learn and does is not as structured as techniques like JAD.

General Brainstorming Session

• Leader opens the session by expressing a general statement of the problem (the seed)
• Participants are then free to generate new ideas relevant to the problem expression
  • Criticism is forbidden
  • Wild, offbeat or unconventional ideas are encouraged
  • The number of ideas generated should be large
  • Participants should be encouraged to combine or embellish ideas of others

Ideas should be recorded on sheets of paper, whiteboards or flipcharts.

The Consolidation phase encourages the group to organize the ideas in ways that they can best be utilized. Evaluation of the ideas takes place.

• Review ideas for clarity. Reword/rewrite if necessary. Combine if necessary
• Discard wild ideas
• Prioritize ideas.

Interviewing

Interviewing is the most common requirements elicitation technique. Interviewing has four phases:

• identifying candidates
  • Typically start with management
• preparing
  • making arrangements
  • preparing questions
• conducting the interview
  • You may not understand the interviewee
  • Typically need to explore answers to improve your understanding
  • Active listening approaches (ie. summarize often, not just at the end)
  • Explain implications and alternatives to interviewee
  • Keep interviewee at ease
• following up
  • Thank interviewee
  • Summarize interview
  • Provide summary to interviewee if they request it

Types of questions to ask:

• Process questions
  • "Are we doing all right?"
  • "Have we ignored anything?"
  • "Did we spend enough time on this issue?"
• Protocol questions (ie context)
  • "Why are we building this system?"
  • "What do you expect from the system?"
  • "Who are the users of this system?"
• Open ended questions. (Elicit a large amount of information)
  • "Tell me what you do".
  • "What aspects of your job are tedious?"
• Closed-ended questions. (Force a precise answer)

Things to avoid:

• Leading questions
  • "How often should the sales reports be generated?" vs "Should the sales reports be generated weekly?"
• Yes or no questions
  • Cause the interviewee to become passive
• Don't anticipate the answer to your questions

When switching between different contexts, make sure that the interviewee knows you are switching contexts.

Interviewing errors

• Focus errors: people focus on different things
• Recall errors: the interviewee might be recalling information from memory
• Interpretation errors: different interpretation of common words
• Ambiguities: natural language errors
• Conflicts: There may be conflict on an issue between interviewer and interviewee
• Incorrect facts: could be judgment or opinion

More structured interview: Debriefing

Used by military, police, psychologists and psychiatrists.

General structure:

• Introduction stage
  • Introduce process
  • May need to address doubts about the effectiveness of this process
• The story stage
  • Invite the person to describe the new system
• The background stage
  • Invite the person to describe the background to the new system
• The retelling stage
  • The intent is to elicit more information
• The "going beyond" stage
  • What are the expectations of the new system
• The Termination stage
  • Reflecting on the process

PIECES Framework

Inexperienced analysts may have difficulty getting started with the process of requirements elicitation. The PIECES framework provides a set of categories which can help to drive the elicitation process.

• P: Performance
• I: Information and data
• E: Economy
• C: Control
• E: Efficiency
• S: Services

Prototyping

Users may be better able to express their needs by comparing them to an existing or reference system.

• Preliminary study of user requirements
• Produce prototype
  • Prototype models appearance or functionality of system
  • Building the prototype must be significantly faster than developing the system
• Elicit feedback

Dangers of Prototyping

• Expectation management
• Trial-and-error programming
• Prototypes are not typically maintainable