Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis is an important aspect of project management.
Requirement prioritization is used in Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
In this Business Analysis training session, you will learn about Requirement Elicitation Techniques. Topics covered in this session are:
• Requirements Engineering
• Project Scope
• Landscape of Requirements
• Properties of Requirements
• Types of Requirements
• Stakeholder
• Requirements Elicitation
• Techniques
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system.
Requirements analysis is the process of refining the user's needs and constraints.
Requirements specification is the process of documenting the user's needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)
Requirement prioritization is used in Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
In this Business Analysis training session, you will learn about Requirement Elicitation Techniques. Topics covered in this session are:
• Requirements Engineering
• Project Scope
• Landscape of Requirements
• Properties of Requirements
• Types of Requirements
• Stakeholder
• Requirements Elicitation
• Techniques
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system.
Requirements analysis is the process of refining the user's needs and constraints.
Requirements specification is the process of documenting the user's needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)
The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model.
This lecture provide a review of requirement engineering process. The slides have been prepared after reading Ian Summerville and Roger Pressman work. This lecture is helpful to understand user, and user requirements.
An operating system (OS) is a software program that manages the resources of a computer system and provides a platform for running applications. Its primary functions include resource management, process management, memory management, file system management, and user interface. There are many different types of operating systems, such as desktop operating systems like Windows and macOS, server operating systems like Linux and Windows Server, and embedded operating systems like those used in mobile phones and other small devices. The choice of operating system depends on the type of device, the intended use, and other factors.
What is a Database?
Database creation steps
Benefits of using Database
Types of Table Relationships
What is a Database model
Database Management System
Users of Database
MS Access
Program, Language, & Programming Language
Object Oriented Programming vs Procedure Oriented Programming
About C
Why still Learn C?
Basic Terms
C Stuff
C Syntax
C Program
Algorithm
What is an algorithm?
How are mathematical statements and algorithms related?
What do algorithms have to do with computers?
Pseudo Code
What is pseudocode?
Writing pseudocode
Pseudo Code vs Algorithm
Components of Data Communication
Characteristics of Data Transmission
Communication Media
Communication Speed
Communication Hardware
Communication Software
OSI Model
Introduction
Syed Zaid Irshad
Rules (that You have to Follow)
Book Introduction
10 Chapters
Theoretical Chapters are 6
Practical Chapters are 4
Chapter 1: Basic Concept of Information Technology
Introduction of Computer
Definition
Characteristics
Parts of Computer
Input
Output
Memory
Primary Storage
Secondary Storage
Ports
Language Translator
Compiler
Interpreter
Generations of Programming Language
Ages of Computers
Generations of Computer
Classification of Computers
Chapter 2: Information Networks
Types of Network
LAN
WAN
MAN
GAN
Topologies
Star
Ring
Bus
Hybrid
File Transfer Protocol
World Wide Web
Chapter 3: Data Communication
Standards
Transmission
Simples
Half Duplex
Full Duplex
Media
Twisted Pair Cable
Coaxial Cable
Fiber Optic Cable
Microwave Transmission
Satellite Transmission
Open Systems Interconnection model (OSI model)
Chapter 4: Applications and Use of Computers
Difference Between Application and Use
Impacts of Computers
Chapter 5: Computer Architecture
Address of Memory Locations
Instruction Format
Fetch and Execute
Chapter 6: Security, Copyright and The Law
Computer Crime
Computer Viruses
Computer Privacy
Software Piracy and Law
Chapter 7: Operating System
User Interface
Graphical User Interface
Operating Systems
Chapter 8: Word Processing
Introduction to MS Word
Creating
Editing
Formatting
Printing
Chapter 9: Spreadsheet
Introduction to MS Excel
Creating
Editing
Formatting
Printing
Formulae
Project
Chapter 10: Internet Browsing and Using E-mail
Create Email ID
Send Mail
Download File
Upload File
Study Plan
Every Tuesday we perform Practical
Every Friday Half of the Lecture will be used as question answer session
Rest of the days are for Theoretical Stuff
Make WhatsApp Group for class where we can share stuff related to the Subject
1st Year Computer Science Book
Sindh Text Book Board Introduction
Introduction
Syed Zaid Irshad
Rules (that You have to Follow)
Book Introduction
10 Chapters
Theoretical Chapters are 6
Practical Chapters are 4
Chapter 1: Basic Concept of Information Technology
Introduction of Computer
Definition
Characteristics
Parts of Computer
Input
Output
Memory
Primary Storage
Secondary Storage
Ports
Language Translator
Compiler
Interpreter
Generations of Programming Language
Ages of Computers
Generations of Computer
Classification of Computers
Chapter 2: Information Networks
Types of Network
LAN
WAN
MAN
GAN
Topologies
Star
Ring
Bus
Hybrid
File Transfer Protocol
World Wide Web
Chapter 3: Data Communication
Standards
Transmission
Simples
Half Duplex
Full Duplex
Media
Twisted Pair Cable
Coaxial Cable
Fiber Optic Cable
Microwave Transmission
Satellite Transmission
Open Systems Interconnection model (OSI model)
Chapter 4: Applications and Use of Computers
Difference Between Application and Use
Impacts of Computers
Chapter 5: Computer Architecture
Address of Memory Locations
Instruction Format
Fetch and Execute
Chapter 6: Security, Copyright and The Law
Computer Crime
Computer Viruses
Computer Privacy
Software Piracy and Law
Chapter 7: Operating System
User Interface
Graphical User Interface
Operating Systems
Chapter 8: Word Processing
Introduction to MS Word
Creating
Editing
Formatting
Printing
Chapter 9: Spreadsheet
Introduction to MS Excel
Creating
Editing
Formatting
Printing
Formulae
Project
Chapter 10: Internet Browsing and Using E-mail
Create Email ID
Send Mail
Download File
Upload File
Study Plan
Every Tuesday we perform Practical
Every Friday Half of the Lecture will be used as question answer session
Rest of the days are for Theoretical Stuff
Make WhatsApp Group for class where we can share stuff related to the Subject
Sachpazis:Terzaghi Bearing Capacity Estimation in simple terms with Calculati...Dr.Costas Sachpazis
Terzaghi's soil bearing capacity theory, developed by Karl Terzaghi, is a fundamental principle in geotechnical engineering used to determine the bearing capacity of shallow foundations. This theory provides a method to calculate the ultimate bearing capacity of soil, which is the maximum load per unit area that the soil can support without undergoing shear failure. The Calculation HTML Code included.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
Explore the innovative world of trenchless pipe repair with our comprehensive guide, "The Benefits and Techniques of Trenchless Pipe Repair." This document delves into the modern methods of repairing underground pipes without the need for extensive excavation, highlighting the numerous advantages and the latest techniques used in the industry.
Learn about the cost savings, reduced environmental impact, and minimal disruption associated with trenchless technology. Discover detailed explanations of popular techniques such as pipe bursting, cured-in-place pipe (CIPP) lining, and directional drilling. Understand how these methods can be applied to various types of infrastructure, from residential plumbing to large-scale municipal systems.
Ideal for homeowners, contractors, engineers, and anyone interested in modern plumbing solutions, this guide provides valuable insights into why trenchless pipe repair is becoming the preferred choice for pipe rehabilitation. Stay informed about the latest advancements and best practices in the field.
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
Student information management system project report ii.pdfKamal Acharya
Our project explains about the student management. This project mainly explains the various actions related to student details. This project shows some ease in adding, editing and deleting the student details. It also provides a less time consuming process for viewing, adding, editing and deleting the marks of the students.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
3. 3
Requirements Elicitation
• Determining the system requirements
through consultation with stakeholders,
from system documents, domain
knowledge, and market studies
• Requirements acquisition or requirements
discovery
4. 4
Requirements Analysis and Negotiation - 1
• Understanding the relationships among
various customer requirements and shaping
those relationships to achieve a successful
result
• Negotiations among different stakeholders
and requirements engineers
Requirements analysis and negotiation activity is
performed by
5. 5
Requirements Analysis and Negotiation - 2
• Incomplete and inconsistent information needs to be tackled
here
• Some analysis and negotiation needs to be done on account
of budgetary constraints
6. 6
Requirements Specification
• Building a tangible model of requirements
using natural language and diagrams
• Building a representation of requirements
that can be assessed for correctness,
completeness, and consistency
Requirements specification includes
7. 7
Requirements Document
• Detailed descriptions of the required software system
in form of requirements is captured in the
requirements document
• Software designers, developers and testers are the
primary users of the document
8. 8
Requirements Validation
• It involves reviewing the requirements model for consistency and
completeness
• This process is intended to detect problems in the requirements
document, before they are used as a basis for the system
development
9. 9
Requirements Management
• Although, it is not shown as a separate
activity in RE Process, it is performed through
out the requirements engineering activities.
• Requirements management asks to identify,
control and track requirements and the
changes that will be made to them
10. 10
Till-Now
• Requirements engineering is the process by which we can
systematically determine the requirements for a software
product
• It is one of the most critical processes of software life cycle
• If performed correctly, it sets the software project on a track
which results in a successful project
11. Requirement Analysis
• Requirement Analysis bridges the gap b/w
Elicitation and requirement specification
Requirement
Elicitation
Requirement
Analysis
Requirement
Specification
12. Requirements Analysis [1]
• What is it?
The process by which customer needs are understood and
documented.
Example 1:
The system shall allow users to withdraw cash. [What?]
Example 2:
A sale item’s name and other attributes will be stored in a hash
table and updated each time any attribute changes. [How?]
Expresses “what” is to be built and NOT “how” it is to be
built.
13. Iterative Aspects of Elicitation, Analysis, and
Negotiation
Requirements
Elicitation
Requirements
Analysis
Requirements
Problems
Requirements
Negotiation
Requirements
Documents
Draft
Statement of
Requirements
14. 14
Requirements Analysis and Negotiation
• We’ll discuss requirements analysis and negotiation
separately, in order to understand them clearly and to
appreciate that different skills are needed to perform them
• They are inter-leaved activities and join to form a major
activity of the requirements engineering process
15. 15
Requirements Analysis - 1
• The aim of requirements analysis is to discover problems
with the system requirements, especially incompleteness
and inconsistencies
• Some analysis is inter-leaved with requirements elicitation as
problems are sometimes obvious as soon as a requirement is
expressed
16. 16
Requirements Analysis - 2
• Detailed analysis usually takes place after the initial draft of the
requirements document is produced
• Analysis is concerned with incomplete set of requirements, which has
not been discussed by stakeholders
18. Necessity Checking
• The need for the requirement is analyzed. In some
cases, requirements may be proposed which don’t
contribute to the business goals of the organization or
to the specific problem to be addressed by the system
19. Consistency and Completeness
Checking
• The requirements are cross-checked for consistency
and completeness. Consistency means that no
requirements should be contradictory; Completeness
means that no services or constraints which are
needed have been missed out
20. Feasibility Checking
• The requirements are checked to ensure that they are
feasible in the context of the budget and schedule
available for the system development
21. 21
Analysis Techniques
• Analysis checklists
• A checklist is a list of questions which analysts may use to assess each
requirement
• Interaction matrices
• Interaction matrices are used to discover interactions between requirements
and to highlight conflicts and overlaps
22. 22
Analysis Checklists - 1
• Each requirement may be assessed against the checklist
• When potential problems are discovered, these should be
noted carefully
• They can be implemented as a spreadsheet, where the rows
are labeled with the requirements identifiers and columns
are the checklist items
23. 23
Analysis Checklists - 2
• The are useful as they provide a reminder of what to look for
and reduce the chances that you will forget some
requirements checks
• They must evolve with the experience of the requirements
analysis process
• The questions should be general, rather than restrictive,
which can be irrelevant for most systems
24. 24
Checklist Items - 1
• Premature design
• Combined requirements
• Unnecessary requirements
• Use of non-standard hardware
25. 25
Checklist Items Description - 1
• Premature design
• Does the requirement include premature design or implementation
information?
• Combined requirements
• Does the description of a requirement describe a single requirement or could
it be broken down into several different requirements?
26. 26
Checklist Items Description - 2
• Unnecessary requirements
• Is the requirement ‘gold plating’? That is, is the requirement a
cosmetic addition to the system which is not really necessary
• Use of non-standard hardware
• Does the requirement mean that non-standard hardware or
software must be used? To make this decision, you need to know
the computer platform requirements
27. 27
Checklist Items - 2
• Conformance with business goals
• Requirements ambiguity
• Requirements realism
• Requirements testability
28. 28
Checklist Items Description - 3
• Conformance with business goals
• Is the requirement consistent with the business goals defined
in the introduction to the requirements document?
• Requirements ambiguity
• Is the requirement ambiguous i.e., could it be read in different
ways by different people? What are the possible
interpretations of the requirement?
29. 29
Checklist Items Description - 4
• Requirements realism
• Is the requirement realistic given the technology which will be
used to implement the system?
• Requirements testability
• Is the requirement testable, that is, is it stated in such a way
that test engineers can derive a test which can show if the
system meets that requirement?
30. 30
Up-till Now
• Discussed requirements analysis, which is an iterative activity
and checks for incomplete and inconsistent requirements
• Studied analysis checklists, and will continue our discussion
of requirements analysis.
• We’ll talk about requirements negotiation.
31. 31
What’s Next
• We’ll spend some time discussing interaction matrices, another
requirements analysis technique
• We’ll talk about requirements negotiation
32. 32
Requirements Interactions - 1
• A very important objective of requirements analysis is to
discover the interactions between requirements and to
highlight requirements conflicts and overlaps
• A requirements interaction matrix shows how requirements
interact with each other, which can be constructed using a
spreadsheet
33. 33
Requirements Interactions - 2
• Each requirement is compared with other requirements, and
the matrix is filled as follows:
• For requirements which conflict, fill in a 1
• For requirements which overlap, fill in a 1000
• For requirements which are independent, fill in a 0
• Consider an example
35. 35
Comments on Interaction Matrices - 1
• If you can’t decide whether requirements conflict, you should assume
that a conflict exists. If an error is made it is usually fairly cheap to fix;
it can be much more expensive to resolve undetected conflicts
36. 36
Comments on Interaction Matrices - 2
• In the example, we are considering, we can see that R1 overlaps with
R3 and conflicts with R5 and R6
• R2 is an independent requirement
• R3 overlaps with R1, R4, and R6
37. 37
Comments on Interaction Matrices - 3
• The advantage of using numeric values for conflicts and
overlaps is that you can sum each row and column to find
the number of conflicts and the number of overlaps
• Requirements which have high values for one or both of
these figures should be carefully examined
38. 38
Comments on Interaction Matrices - 4
• A large number of conflicts or overlaps means that any
changes to that requirement will probably have a major
impact of the rest of the requirements
• Interaction matrices work only when there is relatively small
number of requirements, as each requirement is compared
with every other requirement
39. 39
Comments on Interaction Matrices - 5
• The upper limit should be about 200 requirements
• These overlaps and conflicts have to be discussed and resolved during
requirements negotiation, which we’ll discuss next
41. 41
Requirements Negotiation - 1
• Disagreements about requirements are inevitable
when a system has many stakeholders. Conflicts
are not ‘failures’ but reflect different stakeholder
needs and priorities
• Requirements negotiation is the process of
discussing requirements conflicts and reaching a
compromise that all stakeholders can agree to
42. 42
Requirements Negotiation - 2
• In planning a requirements engineering process, it is important to
leave enough time for negotiation. Finding an acceptable compromise
can be time-consuming
43. 43
Requirements Negotiation - 3
• The final requirements will always be a compromise which is
governed by the needs of the organization in general, the specific
requirements of different stakeholders, design and implementation
constraints, and the budget and schedule for the system development
45. 45
Requirements Discussion
• Requirements which have been highlighted as problematic are
discussed and the stakeholders involved present their views about
the requirements
47. 47
Requirements Agreement
• Solutions to the requirements problems are identified and a
compromised set of requirements are reached. Generally, this will
involve making changes to some of the requirements
49. 49
Comments on Requirements Negotiation - 1
• In principle, requirements negotiation should be an objective process
• The requirements for the system should be based on technical and
organizational needs
50. 50
Comments on Requirements Negotiation - 2
• Negotiations are rarely conducted using only logical and technical
arguments
• They are influenced by organizational and political considerations,
and the personalities of the people involved
51. 51
Comments on Requirements Negotiation - 3
• A strong personality may force their priorities on other
stakeholders
• Requirements may be accepted or rejected because they
strengthen the political influence in the organization of some
stakeholders
• End-users may be resistant to change and may block
requirements, etc.
52. 52
Comments on Requirements Negotiation - 4
• The majority of time in requirements negotiation is usually spent
resolving requirements conflicts. A requirement conflicts with other
requirements if they ask for different things
• Example of access of data in a distributed system
53. 53
Comments on Requirements Negotiation - 5
• Even after years of experience, many companies do not allow enough
time for resolution of conflicts in requirements
• Conflicts should not be viewed as ‘failures’, they are natural and
inevitable – rather healthy
54. 54
Resolution of Requirements Conflicts
• Meetings are the most effective way to negotiate requirements and
resolve requirements conflicts
• All requirements which are in conflict should be discussed individually
• Negotiation meetings should be conducted in three stages
56. 56
Information Stage
• An information stage where the nature of the problems
associated with a requirement is explained
57. 57
Discussion Stage
• A discussion stage where the stakeholders involved discuss
how these problems might be resolved
• All stakeholders with an interest in the requirement should be
given the opportunity to comment. Priorities may be assigned to
requirements at this stage
58. 58
Resolution Stage
• A resolution stage where actions concerning the requirement are
agreed
• These actions might be to delete the requirement, to suggest specific
modifications to the requirement or to elicit further information about the
requirement
59. 59
Up-till Now
• Interaction matrices are very useful for capturing
interactions among requirements
• Requirements negotiation is always necessary to resolve
requirements conflicts and remove requirements overlaps.
Negotiation involves information interchange, discussion and
resolution of disagreements
60. Requirements Analysis [2]
• C- and D-Requirements
C-: Customer wants and needs; expressed in
language understood by the customer.
D-: For the developers; may be more formal.
61. Requirements Analysis [3]
Why document requirements?
• Serves as a contract between the customer and the
developer.
• Serves as a source of test plans.
• Serves to specify project goals and plan development
cycles and increments.
62. Requirements Analysis [4]
• Roadmap:
Identify the customer.
Write C-requirements, review with customer, and update when
necessary.
Interview customer representatives.
Write D-requirements; check to make sure that there is no
inconsistency between the C- and the D-requirements.
63. Requirements Analysis [5]
• C-requirements:
Use cases expressed individually and with a use case diagram. A use
case specifies a collection of scenarios.
Sample use case: Process sale.
Data flow diagram:
Explains the flow of data items across various functions. Useful for
explaining system functions. [Example on the next slide.]
State transition diagram:
Explains the change of system state in response to one or more
operations. [Example two slides later.]
User interface: Generally not a part of requirements analysis though may
be included.
64. Data Flow Diagram
Get employee
file
Total pay
Deduct
taxes
Net pay
Issue
paycheck
Regular
hours
Overtime
hours
ID
Worker
Check
Company records
Employee Record
Tax rates
Pay rate
Weekly
pay* Pay Overtime
pay
*
Overtime
rate
*
65. State Transition Diagram (STD)
EBOFF (e,f) EBON (e,f)
EBP(e,f)
EBP(e,f)
EBOFF (e,f): Elevator e button OFF at floor f.
EBON (e,f): Elevator e button ON at floor f.
EBP(e,f): Elevator e button f is pressed.
Elevator example (partial):
66. Requirements Analysis [6]
• D-requirements:
Organize the D-requirements.
Create sequence diagrams for use cases:
Obtain D-requirements from C-requirements and
customer.
Outline test plans
Inspect
Validate with customer.
Release:
67. Requirements Analysis [7]
• Organize the D-requirements:
• Functional requirements
• The blood pressure monitor will measure the blood pressure and
display it on the in-built screen.
• Non-functional requirements
• Performance
• The blood pressure monitor will complete a reading within 10
seconds.
• Reliability
The blood pressure monitor must have a failure probability of less
than 0.01 during the first 500 readings.
68. Requirements Analysis [8]
• Interface requirements: interaction with the users and other
applications
The blood pressure monitor will have a display screen and
push buttons. The display screen will….
Constraints: timing, accuracy
• The blood pressure monitor will take readings with an
error less than 2%.
69. Requirements Analysis [9]
Properties of D-requirements:
Traceability:Functional requirements
D-requirement inspection report design segment
code segment code inspection report test plan
test report
Traceability:Non-Functional requirements
(a) Isolate each non-functional requirement.
(b) Document each class/function with the related non-
functional requirement.
70. Requirements Analysis [10]
• Testability
It must be possible to test each requirement. Example ?
Categorization and prioritization
71. Prioritizing (Ranking) Use Cases
• Strategy :
• pick the use cases that significantly influence the core
architecture
pick the use cases that are critical to the success of the
business.
a useful rule of thumb - pick the use cases that are the highest
risk!!!
72. Requirements Analysis [11]
Completeness
Self contained, no omissions.
Error conditions
State what happens in case of an error. How should the
implementation react in case of an error condition?
73. Consistency of Requirements
Different requirements must be consistent.
R5.4: When the vehicle is cruising at a speed greater
than 300 mph, a special “watchdog” safety
mechanism will be automatically activated.
Example:
R1.2: The speed of the vehicle will never exceed 250 mph.
74. Requirement Analysis Techniques
• Model requirements
• Draw context diagram and detail diagrams
• Create prototypes
• Analyze feasibility
• Prioritize requirements
• Create data dictionary
• Decision Trees and Decision Tables
• Allocate requirements to subsystems
• Analysis checklists
• Requirements Interactions
75. Model requirements
• Data model
• shows relationships among system objects
• Functional model
• description of the functions that enable the
transformations of system objects
• Behavioral model
• manner in which software responds to events from the
outside world
76. Importance of RE Negotiation
• How the requirements were negotiated is far more important
than how the requirements were specified” (Tom DeMarco,
ICSE 96)
• “Negotiation is the best way to avoid “Death March” projects”
(Ed Yourdon,ICSE 97)
• “Problems with reaching agreement were more critical to my
projects’
• Success than such factors as tools, process maturity, and
design methods”(Mark Weiser, ICSE 97)
78. Requirement Errors
• Errors of omission
• Domain experts easily forget to convey domain knowledge to
requirements engineers, because they consider that to be
obvious and implicit
• Errors of clarity and ambiguity
• Primarily, because natural languages (like English) are used to
state requirements, while such languages are themselves
ambiguous
• Errors of speed and capacity
• These occur due to conflicting understanding or competing
needs of different stakeholders
80. 80
Prevention vs. Removal
• For requirements errors, prevention is usually more effective
than removal
• Joint application development (JAD), quality function
deployment (QFD), and prototyping are more effective in
defect prevention
• Requirements inspections and prototyping play an important
role in defect removal
81. 81
Defect Prevention - 1
• Don’t let defects/errors become part of the requirements document
or requirements model in the first place
• How is it possible?
• Understanding application domain and business area is the first step
in defect prevention
82. 82
Defect Prevention - 2
• Training in different requirements engineering activities
(elicitation, analysis and negotiation, specification, and
validation) is also very important for defect prevention
• Allocating enough time to conduct requirements engineering
activities also is very important in this regard
83. 83
Defect Prevention - 3
• Willing and active participation of stakeholders in different activities
of requirements engineering. That is why JAD is very useful in defect
prevention as far as requirements errors are concerned
84. 84
Defect Prevention - 4
• An overall commitment to quality and emphasis on using
documented processes is also a very important
• An overall commitment to process improvement
85. 85
Q.F.D. - 1
• Quality Function Deployment
• Customer’s needs imply technical requirements:
• Normal requirements
(minimal functional & performance).
• Expected requirements
(important implicit requirements, i.e. ease of use).
• Exciting requirements
(may become normal requirements in the future, highly prized & valued).
86. 86
Q.F.D. - 2
• Function Deployment:
• Determines value of required function.
• Information Deployment:
• Focuses on data objects and events produced or consumed by the system.
• Task Deployment:
• product behavior and implied operating environment.
87. 87
Q.F.D. - 3
• Value Analysis makes use of:
• Customer interviews.
• Observations.
• Surveys.
• Historical data.
• to create
• Customer Voice Table
• extract expected requirements
• derive exciting req.
88. 88
Use Cases
• Scenarios that describe how the product will be used in specific situations.
• Written narratives that describe the role of an actor (user or device) as it interacts
with the system.
• Use-cases designed from the actor's point of view.
• Not all actors can be identified during the first iteration of requirements
elicitation, but it is important to identify the primary actors before developing the
use-cases.
89. 89
User Profile - Example
• Full Control (Administrator)
• Read/Write/Modify All (Manager)
• Read/Write/Modify Own (Inspector)
• Read Only (General Public)
90. 90
Use Case Example - 1
• Read Only Users
• The read-only users will only read the database and cannot insert, delete or
modify any records.
• Read/Write/Modify Own Users
• This level of users will be able to insert new inspection details, facility
information and generate letters. They will be also able to modify the entries
they made in the past.
91. 91
Use Case Example - 2
• Read/Write/Modify All Users
• This level of users will be able to do all the record maintenance tasks. They
will be able to modify any records created by any users.
• Full Control Users
• This is the system administrative level which will be able to change any
application settings, as well as maintaining user profiles.