The document discusses software engineering requirements analysis and specification. It covers topics like software requirements types (functional and non-functional), requirement engineering process, feasibility studies, requirements elicitation and analysis. The requirement engineering process involves activities like requirements discovery, analysis, specification, validation and management. It also discusses preparing a software requirements document that defines system specifications.
Software engineering 18 user interface designVaibhav Khanna
System users often judge a system by its
interface rather than its functionality
λ A poorly designed interface can cause a user to
make catastrophic errors
λ Poor user interface design is the reason why so
many software systems are never used
Software Requirement Specification is a most important topic asked in exams and for presentations in B.Tech comp. engg. This presentation contains all the important topic and deep knowledge of SRS.It includes definition, scope, role, how to write srs, template and template description. It tells how to build SRS and also includes examples for ease.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Software engineering 18 user interface designVaibhav Khanna
System users often judge a system by its
interface rather than its functionality
λ A poorly designed interface can cause a user to
make catastrophic errors
λ Poor user interface design is the reason why so
many software systems are never used
Software Requirement Specification is a most important topic asked in exams and for presentations in B.Tech comp. engg. This presentation contains all the important topic and deep knowledge of SRS.It includes definition, scope, role, how to write srs, template and template description. It tells how to build SRS and also includes examples for ease.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Software engineering task bridging the gap between system requirements engineering and software design.
Provides software designer with a model of:
system information
function
behavior
Model can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.
object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
This is the most important topic of OOAD named as Object Oriented Testing. It is used to prepare a good software which has no bug in it and it performs very fast. <a href="https://harisjamil.pro">Haris Jamil</a>
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.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
Software engineering task bridging the gap between system requirements engineering and software design.
Provides software designer with a model of:
system information
function
behavior
Model can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.
object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
This is the most important topic of OOAD named as Object Oriented Testing. It is used to prepare a good software which has no bug in it and it performs very fast. <a href="https://harisjamil.pro">Haris Jamil</a>
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.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
1 Software Requirements Descriptions and specification.docxjeremylockett77
1
Software Requirements
Descriptions and specifications
of a system
What is a requirement?
• May range from
– a high-level abstract statement of a service
or
– a statement of a system constraint to a
detailed mathematical functional specification
• Requirements may be used for
– a bid for a contract
• must be open to interpretation
– the basis for the contract itself
• must be defined in detail
• Both the above statements may be called
requirements
Example Example
……
4.A.5 The database shall support the generation and control of
configuration objects; that is, objects which are themselves groupings
of other objects in the database. The configuration control facilities
shall allow access to the objects in a version group by the use of an
incomplete name.
……
2
Types of requirements
• Written for customers
– User requirements
• Statements in natural language plus diagrams of the
services the system provides and its operational
constraints.
• Written as a contract between client and
contractor
– System requirements
• A structured document setting out detailed
descriptions of the system services.
• Written for developers
– Software specification
• A detailed software description which can serve as a
basis for a design or implementation.
User requirements readers
• Client managers
• System end-users
• Client engineers
• Contractor managers
• System architects
System requirements readers
• System end-users
• Client engineers
• System architects
• Software developers
Software specification readers
• Client engineers (maybe)
• System architects
• Software developers
3
We will come back to user
and system requirements
Functional requirements
• Statements of services the system
should provide, how the system
should react to particular inputs
and how the system should behave
in particular situations.
Functional requirements
• Describe functionality or system services
• Depend on the type of software,
expected users and the type of system
where the software is used
• Functional user requirements may be
high-level statements of what the
system should do but functional system
requirements should describe the system
services in detail
Examples of functional
requirements
1. The user shall be able to search either
all of the initial set of databases or
select a subset from it.
2. The system shall provide appropriate
viewers for the user to read documents
in the document store.
3. Every order shall be allocated a unique
identifier (ORDER_ID) which the user
shall be able to copy to the account’s
permanent storage area.
4
Requirements imprecision
• Problems arise when requirements are
not precisely stated
• Ambiguous requirements may be
interpreted in different ways by
developers and users
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer fo ...
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
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.
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
CFD Simulation of By-pass Flow in a HRSG module by R&R Consult.pptxR&R Consult
CFD analysis is incredibly effective at solving mysteries and improving the performance of complex systems!
Here's a great example: At a large natural gas-fired power plant, where they use waste heat to generate steam and energy, they were puzzled that their boiler wasn't producing as much steam as expected.
R&R and Tetra Engineering Group Inc. were asked to solve the issue with reduced steam production.
An inspection had shown that a significant amount of hot flue gas was bypassing the boiler tubes, where the heat was supposed to be transferred.
R&R Consult conducted a CFD analysis, which revealed that 6.3% of the flue gas was bypassing the boiler tubes without transferring heat. The analysis also showed that the flue gas was instead being directed along the sides of the boiler and between the modules that were supposed to capture the heat. This was the cause of the reduced performance.
Based on our results, Tetra Engineering installed covering plates to reduce the bypass flow. This improved the boiler's performance and increased electricity production.
It is always satisfying when we can help solve complex challenges like this. Do your systems also need a check-up or optimization? Give us a call!
Work done in cooperation with James Malloy and David Moelling from Tetra Engineering.
More examples of our work https://www.r-r-consult.dk/en/cases-en/
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
2. UNIT II REQUIREMENTS
ANALYSIS AND
SPECIFICATION
Software Requirements: Functional and Non-
Functional, User requirements, System
requirements, Software Requirements
Document – Requirement Engineering
Process: Feasibility Studies, Requirements
elicitation and analysis, requirements
validation, requirements management-
Classical analysis: Structured system Analysis,
Petri Nets- Data Dictionary.
3. Software Requirements
Requirement Engineering:
The process of establishing the services that the
customer requires from a system
the constraints under which it operates and is
developed.
Requirements specify what the system is supposed
to do, but not how the system is to accomplish its
task.
4. Software Requirements
Requirement - It may span a wide range of
statements:
from a high-level abstract statement of a service or
of a system constraint
to a detailed mathematical functional specification
6. Software Requirements
Requirement – User Requirements:
Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
User requirements are defined using natural
language, tables, and diagrams
7. Software Requirements
Requirement – User Requirements:
Problems with natural language
Precision vs. understandability
Functional vs. non-functional requirements
confusion
Requirements mixture
8. Software Requirements
Requirement – User Requirements:
Guidelines:
Prepare a standard format and use it for all requirements.
Apply consistency in the language: ‘shall’ – mandatory
requirements, ‘should’ – desirable requirements.
Avoid the use of computer terminologies. It should be
written in simple language.
9. Software Requirements
Requirement – System Requirements:
More detailed specifications of user requirements
Serve as a basis for designing the system
May be used as part of the system contract
The requirements specify what the system does
and design specifies how it does.
10. Software Requirements
Requirement – System Requirements:
Structured Language Specification:
requirements are written in a standard way.
The requirement become understandable and
expressive.
Uniformity must be maintained.
Graphical model: Sequence Diagram.
12. Software Requirements
Requirement – Domain Requirements:
Requirements that come from the application
domain of the system and that reflect
characteristics of that domain.
These requirements make use of domain
terminologies specific to the specific to the
existing domain concept.
13. Software Requirements
Requirement – Domain Requirements:
These are the specialized requirements and hence
software engineers find it difficult to co-relate the
domain requirements with the system
requirements.
It is important to specify the domain requirements
otherwise the system will not work properly.
14. Functional and non-functional
requirements
Functional requirements
Describe functionality or system services
Statements of services the system should provide,
how the system should react to particular inputs
and how the system should behave in particular
situations.
15. Functional and non-functional
requirements
Functional requirements
It is heavily dependent upon the type of software,
expected users and type of system where the
software is used.
Functional user requirements may be high-level
statements of what the system should do.
Functional system requirements should describe
16. Functional and non-functional
requirements
Functional requirements – Problems:
Requirements imprecision:
Problems arise when functional requirements are
not precisely stated.
Ambiguous requirements may be interpreted in
different ways by developers and users
17. Functional and non-functional
requirements
Functional requirements – Problems:
Requirements completeness and consistency:
Complete : They should include descriptions of all facilities
required.
Consistent: There should be no conflicts or contradictions in the
descriptions of the system facilities
In practice, because of system and environmental complexity, it
is impossible to produce a complete and consistent requirements
document.
18. Functional and non-functional
requirements
Non - Functional requirements:
These define system properties and constraints.
Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
Non-functional requirements may be more critical
than functional requirements. If these are not met,
19. Functional and non-functional
requirements
Non - Functional requirements:
These define system properties and constraints.
Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless
21. Non-functional requirements -
Types
Product requirements:
Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.
Organizational requirements:
Requirements which are a consequence of organizational policies
and procedures e.g. process standards used, implementation
requirements, etc.
22. Non-functional requirements -
Types
External requirements:
Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
23. Non-functional requirements -
Metrics
Reliability: Generate all the updated information in
correct order.
Availability: Any information must be quickly
available from computer to the authorized user.
Security: The application must be password protected.
Maintainability: Any change in requirement occurs
then it should be easily incorporated in an individual
module.
24. Non-functional requirements -
Metrics
Extensibility: Any new requirement occurs then it
should be easily incorporated in an individual module.
Portability: Portable on the desired OS.
Reusability: A segment of source code can be used
again to add new functionalities.
Resource Utilization: Use of resources to its maximum
capability.
25. Non-functional requirements -
Metrics
Property Measure
Speed Processed transactions/second, User/event response time
Screen refresh time
Size Mbytes, Number of ROM chips
Reliability Mean time to failure, Probability of unavailability
Rate of failure occurrence, Availability
Robustness Time to restart after failure, Percentage of events causing
failure, Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
26. Software Requirements Document
The specification of the system.
It should include both a definition and a specification
of requirements.
It should set of what the system should do rather than
how it should do it.
The SRS is useful in estimating cost, planning team
activities, performing tasks and tracking the team’s
progress.
29. Software Requirements Document
General Description
General functionality of the product: System information,
user characteristics, User objective, general constraints placed
on design team.
The features of the user community, including their expected
expertise with software systems and the application domain.
30. Software Requirements Document
Functional requirements:
It describes the possible effects of a software
system, what the system must accomplish.
Short, imperative sentence stating highest ranked
functional requirements.
31. Software Requirements Document
Functional requirements:
Description: A full description of the requirement.
Criticality: Describes how essential this
requirement is to the overall system.
Technical Issues: Describes any design or
implementation
32. Software Requirements Document
Functional requirements:
Cost and Schedule: Describes the relative or
absolute costs of the system.
Risks: Describes the circumstances under which
this requirement might not able to be satisfied.
Dependencies with other requirements: Describes
interactions with other requirements.
33. Software Requirements Document
Interface requirements:
It describes how the software interfaces with other
software products or users for input or output.
User Interfaces:
GUI: It should include a set of screen dumps user
interface features.
CLI: For each command, a description of all
34. Software Requirements Document
Interface requirements:
Hardware interfaces: interfaces to hardware
devices.
Communication interfaces: Describes network
interfaces.
Software interfaces: Describes the application
programming interfaces not included above.
35. Software Requirements Document
Performance requirements: Specifies speed
and memory requirements.
Design constraints: Specifies any constraints
for the design team such as software or
hardware limitations.
37. Software Requirements Document
Operational Scenarios:
It describes a set of scenarios that illustrate, from
the user’s perspective, what will be experienced
when utilizing the system under various situations.
38. Software Requirements Document
Preliminary Schedule:
It provides an initial version of the project plan,
including the major tasks to be accomplished, their
interdependencies, and their tentative start/stop
dates.
Preliminary Budget:
It provides an initial budget for the project.
39. Software Requirements Document
Appendices:
Definitions, Acronyms, Abbreviations: Provides
definitions terms and acronyms can be provided.
References: It provides complete citations to all
documents and meetings referenced.
40. Characteristics of SRS
Correct: The SRS should be made up to date when
appropriate requirements are identified.
Unambiguous – When the requirements are correctly
understood then only it is possible to write an
unambiguous SRS.
Complete – To make the SRS complete, it should be
specified what a software designer wants to create a
software.
41. Characteristics of SRS
Consistent: It should be consistent with
reference to the functionalities identified.
Specific: The requirements should be
mentioned specifically.
Traceable: What is the need for mentioned
requirement? This should be correctly
identified.
42. Requirement Engineering Process
A Requirement Engineering is a process in
which various activities such as discovery,
analysis and validation of system requirements
are done.
45. Requirement Engineering Process
Functions:
Inception: Specifying the beginning of the
software project. Most of the software projects
get started due to business requirements.
Purpose:
basic understanding of the problem
the people who want a solution and the nature of
46. Requirement Engineering Process
Functions:
Elicitation – Requirements discovery
Difficult to understand customer needs:
Unable to specify the scope of the project.
Difficult to understand the problem and Difficult to communicate with the
system engineer about their needs.
The requirements of the customer changes. This creates a problem of
volatility(Instability).
To overcome these problems, requirements are gathered systematically.
47. Requirement Engineering Process
Functions:
Elicitation – Requirements discovery
Difficult to understand customer needs:
Unable to specify the scope of the project.
Difficult to understand the problem and Difficult to communicate with the
system engineer about their needs.
The requirements of the customer changes. This creates a problem of
volatility(Instability).
To overcome these problems, requirements are gathered systematically.
48. Requirement Engineering Process
Functions:
Elaboration: The information about the
requirements is expanded and refined.
The goal of elaboration activity is to prepare a
technical mode of software functions, features
and constraints.
49. Requirement Engineering Process
Functions:
Negotiation:
Customer may demand for more than that is
achieved .
Customer demands for something which cannot
achieved in limited resources.
50. Requirement Engineering Process
Functions:
Specification - can be any one (or more) of the
following:
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
51. Requirement Engineering Process
Functions:
Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or
systems are engineered)
conflicting or unrealistic (unachievable) requirements
52. Requirement Engineering Process
Functions:
Requirement Management:
The process of managing changing requirements
during the requirements engineering process and
system development.
54. Feasibility Studies
Focus:
If the system contributes to organizational
objectives;
If the system can be engineered using current
technology and within budget;
If the system can be integrated with other systems
that are used
56. Feasibility Studies
Questions for people in the organisation
What if the system wasn’t implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?
57. Feasibility Studies
Types:
Technical Feasibility: It is the measure of
technical resources such as hardware
components, software techniques and skilled
persons.
Economical Feasibility: It is the measure
finances or funds are available for proposed
58. Feasibility Studies
Types:
Operational feasibility: It is a measure of how
well the solution of problems or a specific
alternative solution will work in the
organization.
59. Feasibility Studies
Types:
Schedule feasibility: It is the establishment of
time limit for completion of the project. It is
dependent upon available manpower and
economical support for the project.
60. Requirements Elicitation and
Analysis
Sometimes called requirements elicitation or
requirements discovery.
Software engineers communicate with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints.
61. Requirements Elicitation and
Analysis
Stakeholders:
The person(s) who will affected by the system.
Ex: End-user, Managers, System maintenance
engineers, Domain experts and trade union.
62. Requirements Elicitation and
Analysis
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.
Organisational and political factors may influence the
system requirements.
63. Requirements Elicitation and
Analysis- Process
Requ irem
en ts
class ificatio n an d
org anis ation
Requ irem
en ts
prioritizatio n an d
nego tiation
Requ irem
en ts
do cu m
entation
Requ irem
en ts
dis co very
64. Requirements Elicitation and
Analysis- Process
Requirements discovery:
Interacting with stakeholders to discover their
requirements. Domain requirements are also
discovered at this stage.
Requirements classification and organisation:
Groups related requirements and organizes them
into coherent clusters.
65. Requirements Elicitation and
Analysis- Process
Prioritisation and negotiation:
Prioritising requirements and resolving
requirements conflicts.
If there are some unrealistic requirements then
negotiations are made.
Requirements documentation:
Requirements are documented and input into the
66. Requirements Elicitation and
Analysis- Process
Requirement Discovery:
The process of gathering information about the
proposed and existing systems and distilling the
user and system requirements from this
information.
Sources of information include documentation,
system stakeholders and the specifications of
68. Requirements Elicitation and
Analysis- Methods
Interviewing:
The requirement engineering team communicates
the stakeholders by asking them various questions
about the system and its use.
Types:
Closed interviews where a pre-defined set of
questions are answered
69. Requirements Elicitation and
Analysis- Methods
Interviewing:
Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.
70. Requirements Elicitation and
Analysis- Methods
Interviewing - not good for understanding
domain requirements:
Requirements engineers cannot understand specific
domain terminology;
Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn’t worth
articulating.
71. Requirements Elicitation and
Analysis- Methods
Interviewing – Characteristics:
The interviews should be conducted in a free environment
and they should be conducted with open minded approach.
The requirement engineers should listen to stakeholders
with patience.
Interviewee should start the discussion by asking questions
and the requirements should be gathered together.
72. Requirements Elicitation and
Analysis- Methods
Scenario:
The sequence of interactions made by the user
with the software systems.
To formulate actual system requirements.
The interaction sessions.
73. Requirements Elicitation and
Analysis- Methods
Scenario:
A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario
finishes.
74. Requirements Elicitation and
Analysis- Methods
View point:
Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders.
Stakeholders may be classified under different
viewpoints.
75. Requirements Elicitation and
Analysis- Methods
View point – Types:
Interactor viewpoints: People or other systems that
interact directly with the system. In an ATM, the
customer’s and the account database are interactor
VPs.
Indirect viewpoints: Stakeholders who do not use the
system themselves but who influence the
requirements. Ex: Security Staff
76. Requirements Elicitation and
Analysis- Methods
View point – Types:
Domain viewpoints: Domain characteristics and
constraints that influence the requirements.
Ex: In Library system, the rules that are to
followed for reserving the book.
77. Requirements Elicitation and
Analysis- Methods
View point – Examples:
Article
providers
Finance
Library
manager
Library
staff
Users
Interactor
Indirect
All VPs
Classification
system
UI
standards
Domain
External
Staff
Students Cataloguers
System
managers
78. Requirements Elicitation and
Analysis- Methods
Use cases:
To identify individual interactions with the
system.
Use cases are extensively used for requirements
elicitation.
79. Requirements Elicitation and
Analysis- Methods
Use Case Diagram:
Use case diagrams describe the functionality of a
system and users of the system. They contain the
following elements:
Actors - users of a system, including human users
and other systems
Use cases - functionality or services provided by a
81. Requirements Elicitation and
Analysis- Methods
Class Diagram: It describes the static structure
of a system, or how it is structured rather than
how it behaves.
Elements:
Classes: Entities with common characteristics or
features. Attributes, Operations, and Associations
Associations: relationships that relate two or more
83. Requirements Elicitation and
Analysis- Methods
Sequence Diagram: Sequence diagrams
typically show the flow of functionality
through a use case, and consist of the
following components:
Actors , involved in the functionality
Objects , that a system needs to provide the
functionality
85. Requirements Elicitation and
Analysis- Methods
Collaboration Diagrams:
The focus of the collaboration diagram is on the
roles of the objects as they interact to realize a
system function.
These links are labeled using appropriate
messages.
Each message is prefixed with a sequence number
87. Requirements Elicitation and
Analysis- Methods
State Diagram:
State transition diagrams provide a way to model
the various states in which an object can exist.
State transition diagrams model the dynamic
behavior of a system in response to external
events.
States - Possible situations in which an object can
89. Requirements Elicitation and
Analysis- Methods
Activity Diagram:
It describes the activities of a class
It describes the behavior/states of a class in
response to internal processing.
90. Requirements Elicitation and
Analysis- Methods
Activity Diagram – Elements:
Swimlanes - delegate specific actions to objects
within an overall activity
Action States - uninterruptible actions of entities, or
steps in the execution of an algorithm
Action Flows - relationships between the different
action states on an entity
92. Requirements Elicitation and
Analysis- Methods
Ethnography:
A technique of observation which is used to
understand social and organizational requirements.
The system analyst imagines himself as a part of
the working environment in which the system will
be used.
The analyst finds the implicit requirements of the
93. Requirements Elicitation and
Analysis- Methods
Ethnography - Types.
Requirements obtained from working style of
people:
Requirements can be identified from the sequence
of actions that user is performing.
Valid card and Valid PIN must be entered for
getting the money from ATM
94. Requirements Elicitation and
Analysis- Methods
Ethnography - Types.
Requirements obtained from inter-activities
performed by the people:
Sometimes for finding the social requirements the
other people’s activities should be known.
Ex: ATM system the operator can not shutdown the
system if some transaction is in processing.
95. Requirements Validation
A process in which it is checked that whether
the gathered requirements represent the same
system that customer really wants.
96. Requirements Validation
Requirement Checking:
Validity. Does the system provide the functions which best
support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included?
Realism. Can the requirements be implemented given available
budget and technology
Verifiability. Can the requirements be checked?
97. Requirements Validation
Techniques:
Requirements reviews - Systematic manual
analysis of the requirements
Regular reviews should be held while the
requirements definition is being formulated.
Both client and contractor staff should be involved
in reviews.
99. Requirements Validation
Techniques:
Test-case generation - Developing tests for
requirements to check testability
Verifiability - Is the requirement realistically
testable?
Comprehensibility - Is the requirement properly
understood?
101. Requirements Management
Requirements are always 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.
102. Requirements Management
Enduring and volatile requirements:
Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from
domain models
Volatile requirements. Requirements which
103. Requirements Management
Volatile requirements:
Mutable requirements – Change in the environment
Consequential requirements – Changes due to CBS
Emergent requirements – Customer’s understanding
of the system
Compatibility requirements – depend upon the
specific system or business process.
104. Requirements Management
Planning
During the requirements engineering process,
you have to plan:
Requirements identification - How requirements
are individually identified;
A change management process - The process
followed when analysing a requirements change;
105. Requirements Management
Planning
Traceability policies - The amount of
information about requirements relationships
that is maintained;
CASE tool support - The tool support required
to help manage requirements change;
106. Requirements Management
Planning
Traceability policies – Types:
Source Traceability: The links from requirement to
stakeholders who propose these requirements.
Requirement Traceability: The links between
dependent requirements.
Design Traceability: The links from requirements to
design.
110. Requirements Change Management
Problem Analysis and change specification:
To validate the required change.
Change Analysis and costing:
The effect of change using traceability
information.
The cost of such change is estimated
The decision is made on whether to go for
111. Requirements Change Management
Change Implementation
The requirement document has to be modified.
The document has to either re-written or re-
organized.
This can be achieved by making the modularity
112. Structured System Analysis
A technique in which the system requirements
are converted into specifications and then into
computer programs, hardware configurations
and related manual procedures.
113. Structured System Analysis
The system can be modeled using:
Entity Relationship diagram are used to represent
the data model.
Data flow diagram and control flow diagrams are
used to represent the functional model.
114. Structured System Analysis
Designing Data Flow Diagrams:
It is used to model information and function
domain.
Refinement of DFD into greater levels helps the
analyst to perform functional decomposition.
115. Structured System Analysis - Data
Flow Diagrams
Guidelines:
Level 0 DFD. Context level DFD should depict
the system as a single bubble.
Primary input and primary output should be
carefully identified.
While doing the refinement isolate processes, data
objects and data stores to represent the next level.
116. Structured System Analysis - Data
Flow Diagrams
Symbols:
Symbols Description
External Entity: A source of data or a
destination for data.
A process transforms incoming data
flow into outgoing data flow
117. Structured System Analysis - Data
Flow Diagrams
Symbols:
Symbols Description
Data in the system
The flow of information from one
entity to another
118. Structured System Analysis - Data
Flow Diagrams
Rules:
No process can have only outputs or only inputs.
The process must have both outputs and inputs.
The verb phrases in the problem description can
be identified as processes in the system.
There should not be a direct flow between data
stores and external entity. This flow should go
127. Petri Nets
Invented by Carl Adam Petri in 1962
It is used to define the system. It is used for
distributed systems and systems with resource
sharing.
128. Petri Nets
Components:
Places – States of the system
Transitions – Change in the states
Arc – Connects a place with transition
130. Petri Nets
Components:
Set of places P is {p1,p2,p3,p4}
Set of transitions T is {t1,t2}
Input function: I(t1) = {P2,P4}, I(t2) = {P2}
Output function: O(t1) = {P1}, O(t2) = {P3,P3}
131. Petri Nets
A marking of a Petri net is an assignment of
tokens to that Petri net.
.
..
.
P1
P2
P4
P3
t1
t2
132. Petri Nets
Four tokens: one in P1, two in P2, none in P3,
and one in P4.
Represented by the vector (1,2,0,1)
133. Petri Nets
Transition t1 is enabled (ready to fire)
If t1 fires one token is removed from P2, and
one from P4, and one new token is places in
P1
Transition t2 is also enabled.
135. Petri Nets
Transition t1 is enabled (ready to fire)
If t1 fires one token is removed from P2, and
one from P4, and one new token is places in
P1
Transition t2 is also enabled.
137. Data Dictionary
An organized collection of all the data
elements of the system with precise and
rigorous definitions so that user and system
analyst will have a common understanding of
inputs, outputs, components of stores and
intermediate calculations
138. Data Dictionary
Field Name Description
Name Name of the data item.
Aliases Other name of the data item.
Description / Purpose A notation for representing its goal or
context.
Related data item Relevant data item.
Range of value Value between the item.
Data Structure Definition Form of the data item
Where used / How used Input to the process, output from the
process, as a store and external entity
Supplementary information Data types, preset values, restrictions or
limitations.
139. Data Dictionary
Field Name Description
Name Telephone_Number
Aliases Phone_Number, Mobile_Number
Description / Purpose First 2 digit indicates Country Code, Next
4 digits represents district code, Last 6
digit indicates your number, etc.
Where used / How used Address / Visiting Card / Display / read
the Telephone_Number
Format Numeric / Min 6 digit / max 10 digit /
Starts with +, etc..
140. Data Dictionary - Notations
Sl.No. Notation Meaning
1. X = a + b X consists of data elements a & b.
2. X = [a / b] X consists of either data elements a or b.
3. X = a X consists of an optional data element a.
4. X = Y{a} X consists of Y or more occurrence of data
element a.
5. X = {a}z X consists of Z or fever occurrences of data
element a
6. X = y {a} z X consist of some occurrence of data
element a which are between Y and Z.
141. Data Dictionary - Advantages
1. Mechanism for name management. The data
dictionary software can check for name
uniqueness and tell requirements analysts of
name duplications. The names should be used
consisting and should not clash.
2.It serves as a store of organizational
information that can link analysis, design,