Attributes of good software

The software should deliver the required functionality and performance to the user
and should be maintainable, dependable and usable.

- Maintainability
Software must evolve to meet changing needs of the customers. This is a critical
attribute because software change is an inevitable consequence of a changing
business environment.

- Dependability
Software must be trustworthy. Dependability has a range of characteristics, including
reliability, security and safety. Dependable software should not cause physical or
economical damage in the event of system failure.

- Efficiency
It refers to the ability of the software to use system resources in the most effective
and efficient manner. Software should make effective use of storage space and
executive command as per desired timing requirement. Efficiency therefore includes
responsiveness, processing time, and memory utilization, etc.

- Usability
Software must be usable by the users for which it was designed, this means it
should have an appropriate user interface and adequate documentation.

Other Attributes [Related] of good software

- Functionality
It refers to the degree of performance of the software against its intended purpose.

- Reliability
A set of attributes that bear on capability of software to maintain its level of
performance under the given condition for a stated period of time.

- Portability
A set of attributes that bear on the ability of software to be transferred from one
environment to another, without or minimum changes.

- Robustness
It refers to the degree to which the software can keep on functioning in spite of being
provided with invalid data.

- Integrity
It refers to the degree to which Unauthorized Access to the software data can be
prevented.
What is software engineering?

Software engineering is an engineering discipline which is concerned with all

aspects of software production.

Software engineers should

- adopt a systematic and organized approach to their work
- use appropriate tools and techniques depending on
- the problem to be solved,
- the development constraints and
- use the resources available

At the first conference on software engineering in 1968, Fritz Bauer defined software
engineering as “The establishment and use of sound engineering principles in order
to obtain economically developed software that is reliable and works efficiently on
real machines”.

Stephen Schach defined the same as “A discipline whose aim is the production of
quality software, software that is delivered on time, within budget, and that satisfies
its requirements”.

Both the definitions are popular and acceptable to the majority. However, due to the
increase in cost of maintaining software, the objective is now shifting to produce
quality software that is maintainable, delivered on time, within budget, and also
satisfies its requirements.

Differences between software engineering and computer science

Computer science is concerned with theory and fundamentals; software engineering

is concerned with the practicalities of developing and delivering useful software.
Computer science theories are currently insufficient to act as a complete
underpinning for software engineering.
System engineering is concerned with all aspects of computer-based systems
development including hardware, software and process engineering.
Software engineering is part of this process.

System engineers are involved in system specification, architectural design,

integration and deployment.

Generic phases of Software Engineering

1. Definition phase
- It focus on WHAT i.e. to identify what is to be processed
- What functions and performance are desired?
- What design constraints exist?
- What validation criteria are required to define a successful system?
- Identify the key requirements of the systems and the software?
- It performs three major tasks as:
 - Information engineering
- Software project planning
- Requirement analysis

2. Development Phase
- It focuses on HOW i.e. to define how data are to be structured.
- How function is to be implemented within a software architecture?
- How procedural details are to be implemented?
- How are interfaces to be characterized?
- How the design will be translated into a programming language
- How will testing be performed?
- It performs three specific technical tasks as:
- Software design
- Code generation
- Software testing

3. Support Phase
- It focuses on change associated with error correction, adaptations required as the
software environment evolves, and changes due to enhancements brought by the
changing customer requirements.
- Four types of changes are encountered during the support phases:
- Correction: Use of corrective maintenance for any error encountered during
support.
- Adaptation: Use of adaptive maintenance to accommodate changes in the
external environment. Example: Change in the CPU, OS, Business rules, external
product characteristics)
- Enhancement: Use of perfective maintenance that extends the software beyond
its original functional requirements.
- Prevention: Use of preventive maintenance by conducting software re-engineering
to avoid software deterioration and to correct, adopt or enhance its features

Key Challenges facing software engineering

Software Engineering in the 21st century faces three key challenges, i.e., Coping with
legacy systems, coping with increasing diversity and coping with demands for
reduced delivery times.

- Legacy systems: Old, valuable systems which hold the majority of larger software
systems in use must be maintained and updated.
- Heterogeneity: Systems are distributed and include a mix of hardware and
software. The challenge is developing techniques to build dependable software,
which is flexible enough to cope with heterogeneity.
- Delivery: There is increasing pressure for faster delivery of software unlike
time-consuming traditional software engineering techniques. The challenge is
shortening delivery times for large and complex systems without compromising
system quality.
Software Myths

- Software standards provide software engineers with all the guidance they need. The
reality is the standards may be outdated and rarely referred to.
- People with modern computers have all the software development tools they need.
The reality is that CASE tools are more important than hardware to producing high
quality software, yet they are rarely used effectively.
- Adding people is a good way to catch up when a project is behind schedule. The
reality is that adding people only helps the project schedule when it is done in a
planned, well-coordinated manner.
- Giving software projects to outside parties to develop solves software project
management problems. The reality is people who can't manage internal software
development problems will struggle to manage or control the external development
of software too.
- A general statement of objectives from the customer is all that is needed to begin a
software project. The reality is without constant communication between the
customer and the developers it is impossible to build a software product that meets
the customer's real needs.
- Project requirements change continually and change is easy to accommodate in
the software design. The reality is that every change has far-reaching and
unexpected consequences. Changes to software requirements must be managed
very carefully to keep a software project on time and under budget.
- Once a program is written, the software engineer's work is finished. The reality is
that maintaining a piece of software is never done, until the software product is
retired from service.
- There is no way to assess the quality of a piece of software until it is actually
running on some machine. The reality is that one of the most effective quality
assurance practices (formal technical reviews) can be applied to any software
design product and can serve as a quality filter very early in the product life cycle.

Evolving role of software

Software takes on a dual role. It is a product and the vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer hardware or,
a network of computers that are accessible by local hardware. Software is an
information transformer—producing, managing, acquiring, modifying, displaying, or
transmitting information. As the vehicle used to deliver the product, software acts as
the basis for the control of the computer (operating systems), the communication of
information (networks), and the creation and control of other programs (software
tools and environments).

Software delivers the most important product of our time- information. Software
transforms personal data (e.g., an individual's financial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (Internet)
and provides the means for acquiring information in all of its forms.
Summary

Software has become a key element in the evolution of computer-based systems

and products. Over the past 50 years, software has evolved from a specialized
problem solving and information analysis tool to an industry in itself. Since software
is composed of programs, data and documents, each of these items comprises a
configuration that is created as part of the software engineering process. The intent
of software engineering is to provide a framework for building software with higher
quality. Software engineering is the systematic collection of decades of
programming experience together with the innovations made by researchers towards
developing high-quality software in a cost-effective manner.

Software Requirement Specification (SRS)

SRS is the medium through which the client and the user needs are accurately
specified.
Software requirement is the description and specifications of a system.
SRS is a document that completely describes WHAT the proposed system should do
without describing HOW the software will do it.
The basic goal of the requirement phase is to produce the SRS, which describes the
complete external behavior of the proposed software.
A high quality SRS is a prerequisite to high quality software.
A high quality SRS reduces the development cost.

Characteristics of a good SRS

The key characteristics of a good Software Requirement Specification (SRS) include:

- Correctness: The SRS should accurately describe the system to be built.

- Completeness: All desired functionalities and constraints must be defined.
- Consistency: There should be no conflicting requirements or descriptions.
- Unambiguousness: Every requirement is stated clearly and interpreted in only one
way.
- Ranking for importance: Prioritizing requirements to guide the development
process and decision-making.
- Modifiability: The SRS should be structured in such a way that changes can be
made easily and efficiently.
- Verifiability: Each requirement should be verifiable by tests, demonstration, or
analysis.
- Traceability: The origin of each requirement is clear, and it is possible to trace back
to it.
- Testability: The system requirements should be stated in a way that allows for the
creation of test cases.
- Design Independence: The SRS should not impose specific solutions on design or
implementation.
- Understandable by the customer: The document should be comprehensible to the
stakeholders without requiring special expertise.
- Right level of Abstraction: The SRS should describe what the system should do,
not how it should do it, using an appropriate level of detail.

What should the SRS address

The IEEE standard, the basic issues that the SRS writer(s) shall address are the
following:
- Functionality: What is the software supposed to do?
- External interfaces: How does the software interact with people, the system's
hardware, other hardware, and other software?
- Performance: What is the speed, availability, response time, recovery time of
various software functions, etc.?
- Attributes: What are the portability, correctness, maintainability, security, etc.
considerations?
- Design constraints imposed on an implementation: Are there any required
standards in effect, implementation language, policies for database integrity,
resource limits, operating environments, etc.?
Uses of SRS document

- Development team requires it for developing products according to the need.

- Test plans are generated by a testing group based on the described external
behavior.
- Maintenance and support staff need it to understand what the software product is
supposed to do.
- Project managers base their plans and estimates of schedule, effort, and resources
on it.
- Customers rely on it to know what product they can expect.
- As a contract between developer and customer.
- For documentation purposes.
Software Requirements Specification vs. System Requirements Specification

- "Software" and "system" are sometimes used interchangeably as SRS. But, a

software requirements specification provides greater detail than a system
requirements specification.
- A system requirements specification (SyRS) presents general information on the
requirements of a system, which may include both hardware and software, based on
an analysis of business needs.
- A software requirements specification (SRS) details the specific requirements of
the software that is to be developed.
Definition of Requirement

- "Requirements are the descriptions and specifications of a system".

- Software requirements analysis is necessary to avoid creating a software product
that fails to meet the customer's needs.
- Data, functional, and behavioral requirements are elicited from the customer and
refined to create a specification that can be used to design the system.
- Software requirements work products must be reviewed for clarity, completeness,
and consistency.
Types of requirements

- User requirements: Statements in natural language plus diagrams of the services

the system provides and its operational constraints. Written for customers.
- System requirements: A structured document setting out detailed descriptions of
the system services. Written as a contract between client and contractor.
- Software specification: A detailed software description which can serve as a basis
for a design or implementation. Written for developers.
- Domain requirements: Requirements that come from the application domain of the
system and that reflect characteristics of that domain. May be new functional
requirements, constraints on existing requirements or define specific computations.
If domain requirements are not satisfied, the system may be unworkable.

Requirement Engineering

Requirements Engineering provides the appropriate mechanism for understanding

what the customer wants, analyzing the need, assessing feasibility, negotiating a
reasonable solution, specifying the solution unambiguously, validating the
specification, and managing the requirements as they are transformed into an
operational system. Requirement Engineering is the disciplined application of proven
principles, methods, tools, and notations to describe a proposed system's intended
behavior and its association.
Requirement Engineering Process

It is the processes used to discover, analyze, and validate system requirements. The
processes used for RE vary widely depending on the application domain, the people
involved, and the organization developing the requirements. However, there are a
number of generic activities common to all processes can be described in six
distinct steps:
1. Requirements elicitation
2. Requirements analysis and negotiation
3. Requirements specification
4. System modeling
5. Requirements validation
6. Requirements management

The Requirement Engineering Process is outlined in a flowchart, demonstrating the

systematic approach to identifying, analyzing, specifying, and validating the
requirements of a software project. The process includes the following key stages:

1. **Feasibility Study**: An initial investigation to assess the practicality and viability

of the proposed project. The outcome of this stage is a Feasibility Report, which
outlines the findings.
2. **Requirements Elicitation and Analysis**: This stage involves gathering detailed
requirements from stakeholders and analyzing them to ensure they are clear,
feasible, and aligned with business objectives. The information gathered here helps
to develop System Models.

3. **Requirements Specification**: Based on the elicited requirements and analysis,

this stage focuses on documenting the requirements in a detailed and structured
manner. This specification serves as a foundation for system models and further
development.

4. **System Modeling**:
system representation that shows relationships among the system components
System modeling is the process of developing abstract models of a system, with
each model presenting a different view or perspective of that system.
System modeling has now come to mean representing a system using some kind of
graphical notation, which is now almost always based on notations in the Unified
Modeling Language (UML).
System molding helps the analyst to understand the functionality of the system and
models are used to communicate with customers.
Models are used during the requirements engineering process to help derive the
requirements for a system, during the design process to describe the system to
engineers implementing the system and after implementation to document the
system's structure and operation. You may develop models of both the existing
system and the system to be developed:
Models of the existing system are used during requirements engineering. They help
clarify what the existing system does and can be used as a basis for discussing its
strengths and weaknesses. These then lead to requirements for the new system.
Models of the new system are used during requirements engineering to help explain
the proposed requirements to other system stakeholders. Engineers use these
models to discuss design proposals and to document the system for
implementation.

5. **Requirements Validation**: In this critical stage, the specified requirements are

rigorously reviewed and validated to ensure they meet stakeholder needs and
expectations. It ensures the requirements are consistent, complete, and
implementable.

The process emphasizes a continuous feedback loop where insights and

refinements from later stages can inform and adjust earlier stages, ensuring a
comprehensive and coherent set of requirements that guide the system's
development.

6. 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
• Requirement change because:
• 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
• Principal stages consists of:
• Problem analysis: Discuss requirements problem and propose change
• Change analysis and costing: Assess effects of change on other requirements
• Change implementation: Modify requirements document and other documents to
reflect change

Non-functional requirement types

The diagram categorizes non-functional requirements into three main types:

1. **Product requirements**: Specify how the delivered product must behave, e.g.,
execution speed, reliability.
- Subcategories include:
- Efficiency requirements
- Reliability requirements
- Usability requirements
- Performance requirements
- Space requirements

2. **Organizational requirements**: Stem from organizational policies and

procedures, e.g., process standards, implementation requirements.
- Subcategories include:
- Portability requirements
- Delivery requirements
- Implementation requirements
- Standards requirements

3. **External requirements**: Arise from external factors to the system and its
development process, e.g., interoperability, legislative requirements.
- Subcategories include:
- Interoperability requirements
- Ethical requirements
- Privacy requirements
- Safety requirements
- Legislative requirements
Requirements describe What not How

Requirements describe **What** the system will do without detailing **How** it will
be done, producing a large document written in natural language that contains a
description of the system's functionality.

**Challenges in uncovering requirements** include:

- Requirements change.
- Problem of scope.
- Problem of understanding.
- Tight project schedule.
- Communication barriers.
- Market-driven software development.
- Lack of resources.
Step 1: Requirements elicitation
- It is the practice of obtaining the requirements of a system from users, customers,
and other stakeholders. This practice is sometimes referred to as Requirement
gathering.
- The goal is to find out from customers what the product objectives are, what needs
to be done, how the product fits into business needs, and how the product is used on
a daily basis.

**Software Requirements Elicitation Techniques:**

1. **Customer meetings**: The most commonly used technique, involving:

- Use of context-free questions to find out customer's goals and benefits, identify
stakeholders, gain understanding of the problem, determine customer reactions to
proposed solutions, and assess meeting effectiveness.
- If many users are involved, ensure a representative cross-section of users is
interviewed.

2. **Facilitated Action Specification Techniques (FAST):**

- Held at neutral sites, attended by both software engineers and customers.
- Rules established for preparation and participation, with an agenda suggested to
cover important points and allow for brainstorming.
- Meeting controlled by a facilitator (customer, developer, or outsider).
- Use of a definition mechanism (flip charts, stickers, electronic devices, etc.) to
identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements.

Requirements elicitation practices include the following:

- Interviews
- Ethnography
- Questionnaires
- User observation
- Workshops
- Brainstorming
- Use cases
- Role playing
- Prototyping

Problems of Requirement Elicitation

- Problems of scope: The boundary of the system is ill-defined. Or unnecessary
details are provided.
- Problems of understanding: The users are not sure of what they need, and don't
have a full understanding of the problem domain.
- Problems of volatility: The requirements change over time.
- Not having good skills to collect information and cannot understand the group
problem.
- Not well defined the actual Problem.
- Not focus on the requirements of the system but more on the design which is
useless at this stage.
- The requirement should be changeable according to time.
- Lack of analyst knowledge with the problem.
- Lack of user's knowledge also creates problems for elicitation.
- Problem with understanding the language between user and analyst.
- Ignoring or omitting the actual problem.
- The boundary of the problem should be well defined.

Guidelines of Requirements Elicitation

- Assess the business and technical feasibility for the proposed system.
- Identify the people who will help specify requirements.
- Define the technical environment (e.g., computing architecture, operating system,
telecommunication needs) into which the system or product will be placed.
- Identify "domain constraints" (i.e., characteristics of the business environment
specific to the application domain) that limit the functionality or performance of the
system or product to build.
- Define one or more requirements elicitation methods (e.g., interviews, team
meetings, etc.).
- Solicit participation from many people so that requirements are defined from
different points of view.
- Create usage scenarios or use cases to help customers/users better identify key
requirements.

Step 2: Requirements analysis and negotiation

- Requirements are categorized and organized into subsets, relations among
requirements identified, requirements reviewed for correctness, requirements
prioritized based on customer needs.
- This is a software engineering task that bridges the gap between system-level
requirements engineering and software design.
- It provides the software designer with a representation of system information,
function, and behavior that can be translated into data, architectural, and
component-level designs.
- Expect to do a little bit of design during analysis and a little bit of analysis during
design.

Figure: Relationship between System Engineering, Software Requirements

Analysis, and Software Design

This figure presents a Venn diagram that illustrates the overlapping areas among
System Engineering, Software Requirements Analysis, and Software Design. It
visually represents the integral connections between these aspects of software
development:
- **System Engineering** encompasses a broader scope that includes both
requirements and design but also factors beyond the software itself.
- **Software Requirements Analysis** is situated between understanding the
system's needs and translating them into software-specific terms.
- **Software Design** focuses on conceiving the system structure and behavior but
is informed by requirements analysis and constrained by system engineering
principles.

The intersection of all three circles indicates the critical area where comprehensive
understanding, analysis, and design considerations converge for effective software
development.

Problems of Requirements Analysis

- Stakeholders don't know what they really want.
- Stakeholders express requirements in their own terms.
- Different stakeholders may have conflicting requirements.
- Organizational and political factors may influence the system requirements.
- The requirements change during the analysis process. New stakeholders may
emerge, and the business environment may change.

Analysis Principles
- The information domain of the problem must be represented and understood.
- The functions that the software is to perform must be defined.
- Software behavior must be represented.
- Models depicting information, function, and behavior must be partitioned in a
hierarchical manner that uncovers detail.
- The analysis process should move from essential information toward
implementation details.

Requirements Elicitation and Analysis Process

Sometimes called requirements elicitation of requirements discovery, this involves
technical staff working with customers to find out about the application domain, the
services that the system should provide, and the system's operational constraints.
This process may involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc., collectively known as stakeholders.
The process activities include:
- Domain understanding
- Requirements collection
- Classification
- Conflict resolution
- Prioritization
- Requirements checking

Step 3: Requirements Specification

Specification Principles:
- Separate functionality from implementation.
- Develop a behavioral model that describes functional responses to all system
stimuli.
- Define the environment in which the system operates and indicate how the
collection of agents will interact with it.
- Create a behavioral model rather than an implementation model.
- Recognize that the specification must be extensible and tolerant of
incompleteness.
- Establish the content and structure of a specification so that it can be changed
easily.
- Representation format and content should be relevant to the problem.
Representations should be revisable.

Software Requirement Specification

Requirements Specification is the direct result of a requirement analysis and can
refer to:
- Software Requirements Specification (SRS)
- Hardware Requirements Specification

A Software Requirements Specification (SRS) is a complete description of the

behavior of a system to be developed. It includes a set of use cases that describe all
the interactions the users will have with the software. In addition to use cases, the
SRS also contains non-functional requirements (such as performance requirements,
quality standards, or design constraints).

**Candidate format for software requirement specification:**

- Introduction
- Information Description
- Functional Description
- Behavioral Description
- Validation Criteria
- Bibliography and Appendix

Step 4: System Modeling

System representation that shows relationships among the system components.
System modeling is the process of developing abstract models of a system, with
each model presenting a different view or perspective of that system. It has now
come to mean representing a system using some kind of graphical notation, which is
now almost always based on notations in the Unified Modeling Language (UML).

System modeling helps the analyst to understand the functionality of the system and
models are used to communicate with customers. Models are used during the
requirements engineering process to help derive the requirements for a system,
during the design process to describe the system to engineers implementing the
system and after implementation to document the system’s structure and operation.
You may develop models of both the existing system and the system to be
developed:

- Models of the existing system are used during requirements engineering. They help
clarify what the existing system does and can be used as a basis for discussing its
strengths and weaknesses. These then lead to requirements for the new system.
- Models of the new system are used during requirements engineering to help explain
the proposed requirements to other system stakeholders. Engineers use these
models to discuss design proposals and to document the system for
implementation.

System Modeling Process includes:

1. System Context Diagram
2. System Flow Diagram
3. System Specification (Developed by writing narrative descriptions for each
subsystem)

Step 5: Requirements validation

• Requirements validation makes sure that requirements meet stakeholders' goals
and don't conflict with them.
• examines the specification to ensure requirement quality and that work products
conform to agreed upon standards.
• is the process of checking whether the requirements, as identified, do not
contradict the expectations about the system of various stakeholders and do not
contradict each other.
•examines the specification to ensure requirement quality and that work products
conform to agreed upon standards.
•is the process of checking whether the requirements, as identified, do not contradict
the expectations about the system of various stakeholders and do not contradict
each other.
•It is Requirements Quality Control
•It checks for validity, consistency, completeness, realism, verifiability.
Requirements Validation techniques
.1 Requirements reviews:- Systematic manual analysis of the requirements
2.Prototyping:- Using an executable model of the system to check requirements.
3. Test-case generation:- Developing tests for requirements to check testability
4. Automated consistency analysis:- Checking the consistency of a structured
requirements description

Step 6: 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
• Requirement change because:
• 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
• Principal stages consists of:
• Problem analysis: Discuss requirements problem and propose change
• Change analysis and costing: Assess effects of change on other requirements
• Change implementation: Modify requirements document and other documents to
reflect change
Requirement Elicitation and Analysis Techniques
• Interviews/Questionnaire
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Use Case Approach • Ethnography
• Prototyping
• Quality Function Deployment (QFD)

Purpose of Use Case Diagram

Use case diagrams are typically developed in the early stage (Analysis phase) of
development and people often apply use case modeling for the following purposes:
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts together with domain experts

Benefits of Use-Case Modeling

• Provides a tool for capturing functional requirements.
• Assists in decomposing system scope into more manageable pieces.
• Provides a means of communicating with users and other stakeholders concerning
system functionality in a language that is easily understood.
• Provides a means of identifying, assigning, tracking, controlling, and management
system development activities, especially incremental and iterative development.
• Provides an aid in estimating project scope, effort, and schedule.
• Provides a baseline for testing in terms of defining test plans and test cases.
• Provides a baseline for user help systems and manuals as well as system
development documentation.
• Provides a tool for requirements traceability.
• Provides a starting point for the identification of data objects or entities.
• Provides functional specifications for designing user and system interfaces.
• Provides a means of defining database access requirements.
• Provides a framework for driving the system development project

Ethnography
Getting information by observation
One of the goals is to use the viewpoint of the people within the system. The terms
emic and etic are used.
An etic view of the system is the 'outside view' or what the analysts see. An emic
view is the 'inside view' or what the system users see.
The main characteristics of ethnographic studies are:
• analysts observe or possibly even participate in such activities.
• any interviews are conducted in situ,
possibly as informal discussion rather than formal interview.
- there is emphasis on examining the interaction between users.
• there is emphasis on tracing communication links and - there is detailed analysis of
artifacts.

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 predefined set of answers.
questions are
- Open interviews where there is no predefined agenda and a range of issues are
explored with stakeholders.

Feasibility studies
• Feasibility study decides whether or not the proposed system is worthwhile.
• A short focused study that checks
- If the system contributes to organizational objectives;
- fI the system can be engineered using current technology and within budget;
- If the system can be integrated with other systems that are used.