CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233:...
Transcript of CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233:...
![Page 1: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/1.jpg)
CSEB233: Fundamentals
of Software Engineering
Software Requirements
Part 1
Understanding Requirements Engineering
![Page 2: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/2.jpg)
Objectives
• Discuss the concept of requirements and the types ofrequirements
• Explain what Requirements Engineering is, its process,and its importance to product development projects
• Explain and relate requirements elicitation,requirements analysis and negotiation, requirementsspecification, requirements verification and validation,and requirements management activities
• Describe various methods, approaches, and techniquesfor performing and supporting the RequirementsEngineering process
![Page 3: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/3.jpg)
Understanding
Requirements Engineering
Concept and Types of
Requirements
![Page 4: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/4.jpg)
What are ‘Requirements’?
• IEEE Standard Glossary of Software EngineeringTerminology (IEEE, 1990):
A condition or capability needed by a user to solve aproblem or achieve an objective
A condition or capability that shall be met or possessedby a system, system component, product or service tosatisfy a contract, an agreement, standard, specificationor other formally imposed documents
A documented representation of a condition or capabilityas in (1) and (2).
![Page 5: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/5.jpg)
Types of Requirements
• Three types of requirement
Functional Requirements (FR)
Non-functional Requirements (NFR) – also known as
Quality Requirements
Constraints
![Page 6: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/6.jpg)
Functional Requirements
• IEEE Standard Glossary of Software Engineering
Terminology (1990) define FR as:
“a requirement that specifies a function that a system or
system component must be able to perform”
• Function is defined as:
“a defined objective or characteristic action of a system
or component”
For example, a system may have inventory control as its
primary function
![Page 7: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/7.jpg)
Functional Requirements
• Functional requirements relate to the actions (such
as calculate, retrieve, display) that the system or
system component must carry out in order to satisfy
the reason for its existence
(Robertson & Robertson, 1999)
![Page 8: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/8.jpg)
Functional Requirements
• Describe the services a system or component of asystem should perform
• Tell you and your users how the system should react tocertain inputs
• Describe how the system should and/or should notbehave in particular situations
• Must not include quality statement such as 'fast',‘efficient’, ‘usable’, ’reliable’, and etc.
• Are important for the developers to use them to developthe system as expected by the customers
![Page 9: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/9.jpg)
Non-functional Requirements
• A requirement that specifies quality property of the entiresystem, a system component, service or function.
• Quality property is usually associated with the system as awhole and not to individual function.
• It will affect degree of user satisfaction. Product - specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
Organizational - a consequence of organizational policies andprocedures, e.g. process standards used, implementationrequirements, etc.
External - arise from factors which are external to the system andits development process e.g. interoperability requirements,legislative requirements, etc.
![Page 10: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/10.jpg)
Non-functional Requirements
Examples
![Page 11: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/11.jpg)
Non-functional Requirements
Examples
![Page 12: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/12.jpg)
Non-functional Requirements
Examples
![Page 13: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/13.jpg)
Non-functional Requirements
Examples
![Page 14: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/14.jpg)
Constraints
• A constraint is an organizational or technological
requirement that restricts the way in which the
system shall be developed.
• Constraints are non-negotiable and are off-limits
during design trade-offs.
![Page 15: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/15.jpg)
Constraints
• Example constraints:
Cultural constraints• User interfaces shall not contain abusive symbols or graphics for
any culture
Legal constraints• Creation of invoices shall consider the goods and services tax of 6%
Physical constraints• Engine control units in the vehicle interior shall work at
temperatures from -10 to +50 degree celcius
Project constraints• The overall development effort must not exceed RM 1,000,000.
![Page 16: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/16.jpg)
Exercises
• Which of the following are FR, NFR and constraints? The house information system shall generate monthly statements of
allowed and denied accesses.
The release of the locking mechanism shall take 0.8 seconds at most.
If a sensor detects a damage of the window, the system shall inform thesecurity company.
If a correct PIN is entered at the keyboard of the access system, thesystem shall remove the door lock and shall record access date, timeand the PIN entered.
The effort for system development shall not exceed 480 person months.
The user password stored in the system shall be protected againstunauthorized access.
The system shall be developed using Rational Unified Process
![Page 17: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/17.jpg)
Understanding
Requirements Engineering
What is Requirements
Engineering?
![Page 18: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/18.jpg)
What is Requirements Engineering
(RE)?
• “… a relatively new term which has been invented to cover all ofthe activities involved in discovering, documenting, andmaintaining a set of requirements for a computer-based system.
• The use of the term ‘engineering’ implies that systematic andrepeatable techniques should be used to ensure that systems arecomplete, consistent, relevant, etc”.
Sommerville & Sawyer (1997)
• “the process of developing a requirements specification”Pohl (1996)
• “the broad spectrum of tasks and techniques that lead to anunderstanding of requirements”
Pressman (2009)
![Page 19: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/19.jpg)
Why is RE important?
• RE process can influence the development cost, time,effort, and quality of the product
• RE process is an essential contributor to the overallquality of the software product
• “Incomplete requirements”, “changing requirements”are major causes of project failures
• Good RE practices contribute more than 42% towardsthe overall success of a project, while improper REpractices account for more than 43% of the reasonswhy projects are late or over budget
(CHAOS, 1995)
![Page 20: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/20.jpg)
How Far Have We Got?
![Page 21: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/21.jpg)
How Far Have We Got?
![Page 22: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/22.jpg)
Importance of RE
(http:/
/ww
w.p
roje
ctc
art
oon.c
om
)
How the customer explain it
How the project leader understood it
How the analyst design it
How the programmer wrote it
How the business
consultant described it
How the project was documented
What operations installed
How the customer was billed How it was supported
What the customer really needed
![Page 23: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/23.jpg)
RE Framework
![Page 24: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/24.jpg)
Framework Motivation
• Structuring requirements engineering by defining a set ofcore common concepts for each requirements engineeringprocess and their relationships
• Reference structure for industry
Training of managers, requirements engineers and developers.
Analysis of strength and weaknesses of RE processes.
• Reference structure for teaching requirements engineering
• Successfully introduced in a number of organizations,companies and universities!
![Page 25: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/25.jpg)
Context
• The requirements engineering context consists of1. The system context is the part of the context in which the
system to be developed is operating/embedded.• Subject facet comprises system context objects about which information is
represented in the system or which influence or constrain therepresentation of information represented in the system.
• Usage facet comprises all system context objects (people and/or systems)which directly or indirectly interact with the system or which influence orbenefit from the usage of the system.
• IT system facet comprises all system context objects of the technical andoperational environment in which the system is going to be deployed in orwhich influence or constraint the deployment of the system and/or the useof technology by the system such as sensors, actuators or other systems.
2. The development context is the part of the context in which thesystem is being developed.
![Page 26: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/26.jpg)
Core Activities
• Elicitation
• Negotiation
• Documentation
![Page 27: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/27.jpg)
Elicitation
• The goal of the elicitation activity is to:1. Identify relevant requirements sources
2. Elicit existing requirements from the identified sources
3. Develop new and innovative requirement
• Requirements sources are not always known at the beginningof the process!
• Relevant requirements sources include: Stakeholders involved in the process,
existing documents
existing systems
![Page 28: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/28.jpg)
Negotiation
• The goal of the negotiation activity is to:
1. Identify conflicts
2. Analyse the cause of each conflict.
3. Resolve the conflicts by means of appropriate strategies.
4. Document conflict resolution and their rationale.
• Wishes and needs of the stakeholders typically varyand can be in conflict
• Conflicts shall be identified and should be resolved
![Page 29: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/29.jpg)
Documentation
• The goal of the documentation activity is to:1. Document relevant requirements information according to the defined
documentation guidelines.
2. Specify requirements according to the defined specification guidelines.
3. Choose documentation formats and notations which fit the stakeholderneeds, and are defined for the project.
4. Ensure consistency between different documentation formats used.
• In addition to the requirements, information about elicitation andnegotiation should be documented.
• Early in requirements engineering, information is oftendocumented informally/unstructured and thus not compliant withthe documentation and specification rules.
![Page 30: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/30.jpg)
Artefacts
• A goal describes a high level objective of one or morestakeholders about a property of the system to be developed orthe development project
• A scenario describes a concrete example of satisfying or failing tosatisfy a goal (or set of goals).
• Three Types of Solution-oriented Requirements Data perspective considers the static data structures. It defines data
types, attributes and relationships between data types.
Functional perspective considers the manipulation of data by systemfunctions. It defines the transformation of inputs by functions intooutputs.
Behavioural perspective considers the system behaviour. It defines thereactions to external stimuli in form of permitted states, transitions andoutputs.
![Page 31: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/31.jpg)
Three types of Solution-oriented
Requirements
![Page 32: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/32.jpg)
Cross-sectional activities
• Validation
• Management
![Page 33: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/33.jpg)
Validation
Three Validation Goals
• Validation of requirement artifacts Aims at detecting defects in requirements.
• Validating the artefacts with regard to the content, the documentation and the agreementdimensions.
• Checking the fulfilment of validation criteria.
• Validation of the core activities Checking the compliance of the activities performed and the process and/or activity
specifications.• Have all required steps been performed?
• Have the required stakeholders been involved in the activities?
• Validation of the context consideration Checking whether the context has been considered adequately in the activities.
• Have all relevant requirements sources been considered?
• Have the required stakeholders been involved?
• Have all parts of the requirements engineering context been sufficiently considered?
![Page 34: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/34.jpg)
Management
Three Management Goals
• Management of the requirements artifacts throughout the system lifecycle: Prioritization of requirements.
Persistent recording.
Configuration management.
Change management.
Requirements traceability.
• Management of the core activities Ensure an efficient and effective overall RE process.
Plan and control the execution of the RE activities.
Alignment of the process to the current project situation.
• Management of the context Identifying changes in the context relevant for the system.
Changes typically require (re-)initiating or (re-)scheduling of one or more RE activities.
![Page 35: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/35.jpg)
Understanding
Requirements Engineering
Requirements Elicitation
![Page 36: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/36.jpg)
Goal
• As mentioned earlier, the goal of the elicitation activityis threefold.1. To identify relevant requirements sources
2. To elicit existing requirements from the identified sources
3. To develop new and innovative requirement
• Three types of requirements sources Documents
Existing systems
Stakeholders
![Page 37: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/37.jpg)
Sources
• Documents Existing documents contain relevant information to be considered when
defining the requirements for the desired system.
Documents can be general (e.g. standards), organization specific (e.g.development guidelines) or product-specific (e.g. code, user manual).
• Stakeholders Either a person or an organization with potential interest in the desired
system.
A person can represent the interest of different stakeholders.
• Existing systems Requirements realized by the existing system might still be relevant for
the new system.
Existing systems can be used to identify enhancements, knowndeficiencies and previous errors.
![Page 38: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/38.jpg)
Elicitation Components
• Four components of requirements elicitation:
Understanding application domain• this is about knowledge of the general area where the system is applied.
Understanding problem to be solved• understand details of the problem where the software will be applied.
Understanding business processes in an organization• understand how systems interact and affect the different part of the
business and how they contribute to overall business goals.
Understanding the needs and constraints of the stakeholders• understand the work processes that the system is intended to support, the
ways in which the system is likely to be used, and restrictions on thedegree of freedom we have in providing a solution.
![Page 39: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/39.jpg)
Main Elicitation Techniques
• Interview Elicitation of requirements and context information from a stakeholder or a group of
stakeholders
• Workshop A group of stakeholders develops requirements for a system
• Focus Group A group of stakeholders focus on a specific item to identify the requirements regarding
this item
• Observation An observer elicits requirements by observing stakeholders of existing systems
• Questionnaire A stakeholder writes down his requirements by answering predefined questions
• Perspective-based Reading A stakeholder reads a document from a previously defined perspective, e.g. from the
perspective of a user or from the perspective of a tester
![Page 40: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/40.jpg)
Other Supporting Techniques
• Brainstorming
• Prototyping
• KJ method
• Mind mapping
• Elicitation checklists
![Page 41: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/41.jpg)
Elicitation Work Products
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders whoparticipated in requirements elicitation
• A description of the system’s technical environment
• A list of requirements (preferably organized by function) andthe domain constraints that apply to each
• A set of usage scenarios that provide insight into the use ofthe system or product under different operating conditions
• Any prototypes developed to better define requirements
![Page 42: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/42.jpg)
Why is it difficult to understand what
the customer wants?
• Problems of scope
System/software boundary is ill-defined
Customers/users specify unnecessary technical detail
that may confuse overall system/software objectives
• Problems of volatility
Requirements change over time
(Christel and Kang, 1992)
![Page 43: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/43.jpg)
Why is it difficult to understand what
the customer wants?
• Problems of Understanding
Customers/users not sure what they want
Poor understanding of the capabilities and limitations of theirown computing environment
Don’t have full understanding of the domain problems
Have trouble communicating need
Omit information that is believed to be “obvious”
Specify ambiguous requirements• “I want a user friendly interface in the XYZ system”.
Specify conflicting requirements
![Page 44: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/44.jpg)
Understanding
Requirements Engineering
Requirements Negotiation
![Page 45: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/45.jpg)
Goal
• A process of discussing the conflicts in therequirements and finding resolutions to theidentified conflicts
• The goal of the negotiation activity is to:
1. Identify conflicts
2. Analyse the cause of each conflict.
3. Resolve the conflicts by means of appropriatestrategies.
4. Document conflict resolution and their rationale.
![Page 46: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/46.jpg)
Conflict
• A conflict in requirements engineering exists, if theneeds and wishes of different stakeholdersregarding the system contradict each other, or ifneeds and wishes cannot be considered.
• Unresolved conflicts have negative impact on theacceptance of the system by the stakeholder.
• When resolving conflicts, often new ideas andinnovative requirements are developed – thusconflicts should be positively seen as opportunities!
![Page 47: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/47.jpg)
Conflict Examples
• A group of stakeholders demands the use of radarsensors for distance measurement. Another groupof stakeholders asks, instead, for ultrasoundsensors.
• A stakeholder demands to display safety-relevantinformation for the driver on a head-up display.Other stakeholders argue this would detract thedriver and hence reject this requirement.
![Page 48: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/48.jpg)
Conflicts
• In any set of requirements, there will always be
conflicts, overlaps, and omissions
• Developer must anticipate these and plan requirements
negotiation with all stakeholders to discuss and resolve
the problems
• Requirements conflicts are inevitable because different
stakeholders have different requirements and priorities
• One technique to identify conflicts and overlaps is by
using Interaction Matrix
![Page 49: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/49.jpg)
Types of Conflict
• Data conflict Wrong, incomplete information about requirements, different interpretation,
different views and different assessment
• Interest conflict Interests or goals with regard to the system contradict each other
• Value conflict Different ways of life, ideology or religion resulting in each stakeholder
considering the importance of a requirement differently.
• Relationship conflict Strong emotions, deficient communication and negative interpersonal behavior
between stakeholders
• Structural conflict Unequal balance of authority or power, destructive patterns of interaction,
unequal control, ownership or distribution of resources and time constraints
![Page 50: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/50.jpg)
Conflicts Resolution
• Three basic strategies for resolving data, value and
interest conflicts.
Negotiation
• The conflict parties agree on a solution by means of negotiation
Creative solution
• The original viewpoints of the conflicting parties are discarded and a
new, creative unanimous solution is developed.
Decision
• A higher authority makes a decision in favour of one conflicting
party.
![Page 51: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/51.jpg)
Prioritizing Requirements
• To decide which requirements have to be
implemented and deliver first, which ones could be
implemented in the subsequent deliveries, and
which ones could be dropped.
• Must collaborate with the customers. Why?
You may not know which requirements are most
important to customers, and
Customers may not be able to judge the cost and
technical difficulty associated with specific requirements.
![Page 52: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/52.jpg)
Techniques of Requirements
Prioritization
• Prioritization scale - A common approach to prioritization is togroup requirements into several priority categories.
E.g.: MoSCoW method (Coley Consulting, 2008)• M - MUST have this.
• S - SHOULD have this if at all possible.
• C - COULD have this if it does not affect anything else.
• W - WON'T have this time but WOULD like in the future
• Quality Function Deployment
• Semi-quantitative Analytical Approach - the requirements’priority can be calculated once you have estimated thebenefit, penalty, cost and risk for the negotiable requirements
![Page 53: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/53.jpg)
Understanding
Requirements Engineering
Requirements Documentation
![Page 54: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/54.jpg)
Why Documentation?
• Persistence – to preserve information that otherwise might beforgotten
• Common reference
• Promotes communication – by having common reference torefer to
• Promotes objectivity – to preserve information from unwantedalteration
• Support training of new employees
• Preserve expert knowledge
• Support problem reflection – by filling up gaps andinconsitencies
![Page 55: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/55.jpg)
What to be Documented?
![Page 56: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/56.jpg)
What to be Documented?
![Page 57: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/57.jpg)
How to Document?
• Textual Natural language text
Structured text
Templates
• Model-based Data perspective
Behaviour perspective
Functional perspective
• Combined Models with annotations
Text with models
![Page 58: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/58.jpg)
Textual (using template)
![Page 59: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/59.jpg)
Model-based
![Page 60: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/60.jpg)
Combined
![Page 61: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/61.jpg)
Requirements Specification
• Also known as Software RequirementsSpecification (SRS)
• A specific kind of requirements document whichsupports later development activities and/or used ascontracts.
• It is an official document that consists of informationthat should guide the system developers such asdesigners, programmers, and engineers through thedevelopment work of the product
![Page 62: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/62.jpg)
Requirements Specification
• Should involve technical writers
appropriate skills for gathering requirements, reviewing
historic reports, writing formal documents and reports,
and etc.
can better assess and plan documentation tasks
know how to determine the questions that are of
concern to the customers and users regarding non-
functional requirements like ease of use and usability
![Page 63: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/63.jpg)
Software Requirements
Specification (SRS)
• Attributes of a well-written SRS (IEEE Standard 830-1998 ): Correct
Unambiguous
Complete
Consistent
Ranked for importance or stability
Verifiable
Testable
Traceable
• SRS template: http://www.processimpact.com/process_assets/srs_template.doc
![Page 64: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/64.jpg)
Understanding
Requirements Engineering
Cross Sectional: Requirements
Validation
![Page 65: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/65.jpg)
Requirements Validation
• Validation denotes checking whether inputs (context
artefacts and consideration), execution and outputs
(requirements artefacts and additional information)
of the RE core activities fulfill defined quality criteria.
• Validation is performed by involving relevant
stakeholders, other requirement sources as well as
external reviewers if necessary.
![Page 66: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/66.jpg)
Validation Goals
![Page 67: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/67.jpg)
Validation versus Verification
![Page 68: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/68.jpg)
Validation Techniques
• Reviews the requirements specification
Desk-check
Walkthrough
Inspection
Checklist
• Prototyping
• Acceptance Tests
![Page 69: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/69.jpg)
Understanding
Requirements Engineering
Cross Sectional: Requirements
Management
![Page 70: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/70.jpg)
Requirements Management
• ‘Ripple Effect’ – one thing causes a series of other things tohappen (e.g., Tsunami)
• Changes in requirements specified in a requirementsdocument are inevitable and must be allowed
• However, even seemingly a minor change may unexpectedlyrequire lot of work
• Main activities in managing requirements artefacts: Managing changes to requirements
Managing configuration of requirements and requirementsdocument – version control
Maintaining requirements traceability
Tracking requirements status
![Page 71: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/71.jpg)
Ripple Effect
![Page 72: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/72.jpg)
Why Requirements Change?
Internal Factors External Factors
1. Failure to elicit the real requirements of the
stakeholders
2. Iterating from requirements to design
creates new requirements
3. The implementation team might encounter
technical, schedule and/or cost problems
in implementing a requirement
4. RE process is iterative and must create a
practical process to help manage changing
requirements. Failure to create a practical
requirements change management
process will only cause rework and stress
1. The problem we are trying to solve
somehow change as a result of a changing
economy, government regulations,
consumer preferences etc.
2. Customers and users understand better
what they really require from a system or
simply change their minds
3. The customers’ organization may change
its structure, procedures and processes
4. The external environment change, which
create new constraints and opportunities
![Page 73: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/73.jpg)
Managing Requirements Changes
• Formal change management is crucial to ensure
that the requirements changes maintain the
proposed system’s support to the fundamental
business goals
• To ensure a consistent approach to change
management, organizations should define a set of
change management policies and procedures
![Page 74: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/74.jpg)
Managing Requirements Changes
• Basic policies:
The change management process – includes change
management principles and guidelines, and activities of
the change management process.
The change impact analysis – needed to avoid changes
from causing overruns in project schedule and budget,
or resulting negative impact on the product’s quality.
![Page 75: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/75.jpg)
Requirements Configuration
Management
• Means detail recording and updating that have been appliedto the requirements document, and providing version control,release management, and issue tracking.
• Benefits (Leffingwell and Widrig, 2003): Prevents any unauthorised and potentially destructive changes to
the requirements.
Preserves the revisions to requirements document.
Facilitates the retrieval and/or recreation of requirementsdocument archives.
Prevents simultaneous updates of requirements documents.
Prevents conflicting and uncoordinated updates to differentdocument at the same time.
![Page 76: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/76.jpg)
Managing Requirements
Traceability
• “The ability to describe and follow the life of arequirement, in both a forward and backward direction,i.e. from its origins, through its development andspecification, to its subsequent deployment and use,and through periods of ongoing refinement and iterationin any of these phases”
(Gotel and Finkelstein, 1994)
• Technique: traceability matrix
to show the dependencies between requirements or linksbetween requirements and other system documents
![Page 77: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/77.jpg)
Traceability Matrix
Use
case
Functional
Requirements
Design
Element
Code Test Case
UC-28 catalog.query.sort Class catalog catalog.sort() search.7
search.8
UC-29 catalog.query.import Class catalog catalog.import()
catalog.validate()
search.8
search.13
search.14
![Page 78: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/78.jpg)
Tracking Requirements Status
• Monitoring implementation status of each requirement to ensure existing requirements are addressed and traceable
throughout the development life cycle
• Tracking requirements status supports overall project statustracking. e.g. proposed, approved, implemented, verified, deleted, rejected
• “If a project manager knows that 55% of the requirementsallocated to the next release have been implemented andverified, 28% are implemented but not verified, and 17% arenot yet fully implemented, then he or she has good insightinto the project status”
(Wiegers, 1999a)
![Page 79: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/79.jpg)
Summary
• The concept of requirements and types of requirements
• What Requirements Engineering is, its process, and theimportance of them to product development projects ingeneral
• What requirements elicitation, requirements analysisand negotiation, requirements specification,requirements verification and validation, andrequirements management tasks are
• Various methods, approaches, and techniques forperforming and supporting the RE process
![Page 80: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding](https://reader035.fdocuments.net/reader035/viewer/2022070218/6123d2d7306d340cdb46015a/html5/thumbnails/80.jpg)
THE END
Copyright © 2014
College of Information Technology