1

Software
Requirement
Engineering
BY:
DR. NADEEM KAJLA
Software Requirement Process: 2

 It focuses on assessing if the system is useful to the business (feasibility

study), discovering requirements (elicitation and analysis),
converting these requirements into some standard format
(specification), and checking that the requirements define the
system that the customer wants (validation).
 3
 requirements engineering is not a sequential process, it’s an iterative
process in which activities are interleaved.

Start
(Feasibility Elicitation
Study)

Validation Specification
Feasibility Study: 4

 feasibility study is a measure of the software product in terms of how

much beneficial product development will be for the organization in
a practical point of view.
 It is a feasibility analysis.
 Feasibility study is carried out based on many purposes to analyze
whether software product will be right in terms of development,
implantation, contribution of project to the organization etc.
Types of Feasibility Study : 5

The feasibility study mainly concentrates on below five mentioned

areas.
Technical Feasibility
Operational Feasibility
Economic Feasibility
Legal Feasibility
Schedule Feasibility
Technical Feasibility 6

 This technical feasibility study gives report whether there exists

correct required resources and technologies which will be used for
project development.
 This feasibility study also analyzes technical skills and capabilities of
technical team
 Existing technology can be used or not
 Maintenance and up-gradation is easy or not for chosen
technology etc.
Operational Feasibility 7

 In Operational Feasibility degree of providing service to

requirements is analyzed along with how much easy product will be
to operate and maintenance after deployment.
 Along with this other operational scopes are determining usability of
product, Determining suggested solution by software development
team is acceptable or not etc.
Economic Feasibility 8

 In Economic Feasibility study cost and benefit of the project is

analyzed.
 Under this feasibility study a detail analysis is carried out what will be
cost of the project for development which includes all required cost
for final development like hardware and software resource required,
design and development cost and operational cost and so on
Legal Feasibility 9

 In Legal Feasibility study project is analyzed in legality point of view.

 This includes analyzing barriers of legal implementation of project,
data protection acts or social media laws, project certificate,
license, copyright etc.
 Overall it can be said that Legal Feasibility Study is study to know if
proposed project conform legal and ethical requirements.
Schedule Feasibility 10

 Timelines/deadlines is analyzed
 How many times teams will take to complete final project
 Which has a great impact on the organization as purpose of project
may fail if it can’t be completed on time.
Elicitation 11

 Elicitation encompasses all of the activities involved with discovering

requirements.
 such as interviews, workshops, document analysis, prototyping, and
others.
 12
The key actions are:
 Identifying the product’s expected user classes and other
stakeholders.
 Understanding user tasks and goals and the business objectives with
which those tasks align.
 Learning about the environment in which the new product will be
used.
 Working with individuals who represent each user class to understand
their functionality needs and their quality expectations
13
Requirements elicitation techniques 14

Elicitation techniques include both facilitated activities, in which you

interact with stakeholders to elicit requirements, and independent
activities, in which you work on your own to discover information.
 Interview
 Workshops
 Focus Groups
 Observations
 Questionnaires
 System Interface analysis
 User Interface analysis
 Document Analysis
Interviews: 15

 The most obvious way to find out what the users of a software system
need is to ask them.
 Interviews are a traditional source of requirements input for both
commercial products and information systems, across all software
development approaches
These are useful tips for conducting elicitation Interviews 16

 Establish rapport
 Introduce yourself and address any preliminary questions or concerns
attendees have.
 Stay in scope
 keep the discussion focused on its objective. Even when you are talking with
just one person or a small group, there’s a chance the interview will go off
topic.
 Prepare questions and straw man models ahead of time:
 Prepare for interviews by drafting any materials you can beforehand, such
as a list of questions to guide the conversation. Draft materials will give your
users a starting point to think from.
 Suggest ideas
17
 Rather than simply transcribing what customers say, a creative BA proposes
ideas and alternatives during elicitation.
 Sometimes users don’t realize the capabilities developers can provide; they
might get excited when you suggest functionality that will make the system
especially valuable.
 Listen actively
 Practice the techniques of active listening (leaning forward, showing
patience, giving verbal feedback, and inquiring when something is unclear)
and paraphrasing (restating the main idea of a speaker’s message to show
your understanding of that message).
Workshops 18

 “a structured meeting in which a carefully selected group of

stakeholders and content experts work together to define, create,
refine, and reach closure on deliverables (such as models and
documents) that represent user requirements.”
 Workshops are facilitated sessions with multiple stakeholders and
formal roles
Following are a few tips for conducting effective elicitation workshops. 19

 Establish and enforce ground rules

 The workshop participants should agree on some basic operating principles.
 Examples include starting and ending on time;
 returning from breaks promptly;
 silencing electronic devices;
 holding one conversation at a time;
 expecting everyone to contribute;

 Fill all of the team roles

 A facilitator must make sure that the following tasks …….
 20
 Plan an agenda
 Each workshop needs a clear plan.
 Create the plan and workshop agenda ahead of time, and communicate
them to participants so they know the objectives and what to expect and
can prepare accordingly.
 Stay in scope
 Keep each workshop focused on the right level of abstraction for that
session’s objectives.
 Groups easily dive into distracting detail during requirements discussions.
 Those discussions consume time that the group should spend on developing
a higher-level understanding of user requirements.
 The facilitator will have to reel in the elicitation participants periodically to
keep them on topic.
 Timebox discussions 21
 Consider allocating a fixed period of time to each discussion topic.
 The discussion might need to be completed later, but timeboxing helps avoid the
trap of spending far more time than intended on the first topic and neglecting
other important topics entirely.
 Keep the team small but include the right stakeholders
 Small groups can work much faster than larger teams.
 Elicitation workshops with more than five or six active participants can become
mired in side trips, concurrent conversations, and bickering.
 Consider running multiple workshops in parallel to explore the requirements of
different user classes.
 Keep everyone engaged
 Sometimes certain participants will stop contributing to the discussion.
 These people might be frustrated for a variety of reasons.
 their input isn’t being taken seriously because other participants don’t find their
concerns interesting
 maybe they don’t want to disrupt the work that the group has completed so far
Focus groups 22

 A focus group is a representative group of users who convene in a

facilitated elicitation activity to generate input and ideas on a
product’s functional and quality requirements.
 Focus group sessions must be interactive, allowing all users a chance to
voice their thoughts.
 Focus groups are useful for exploring users’ attitudes, impressions,
preferences, and needs.
Observations 23

 you can learn a lot by observing exactly how users perform their
tasks.
 Observations are time consuming.
 It is not suitable for every user or every task.
 To avoid disrupting the users’ regularly assigned work activities, limit
each observation time to two hours or less.
 Select important or high-risk tasks and multiple user classes for
observations.
 24
 Observations can be silent or interactive.
 Silent observations are appropriate when busy users cannot be
interrupted.
 Interactive observations allow the BA to interrupt the user mid-task and
ask a question.
Questionnaires 25

 Questionnaires are a way to survey large groups of users to understand

their needs.
 They are inexpensive, making them a logical choice for eliciting
information from large user populations.
 They can be administered easily across geographical boundaries.
 The analyzed results of questionnaires can be used as an input to other
elicitation techniques.
 Preparing well-written questions is the biggest challenge with
questionnaires.
Tips for a good Questionnaire 26

 Provide answer options that cover the full set of possible responses.
 Make answer choices both mutually exclusive (no overlaps in numerical
ranges) and exhaustive (list all possible choices and/or have a write-in spot for
a choice you didn’t think of).
 Don’t phrase a question in a way that implies a “correct” answer.
 If you use scales, use them consistently throughout the questionnaire.
 Use closed questions with two or more specific choices if you want to use the
questionnaire results for statistical analysis. Open-ended questions allows users
to respond any way they want, so it’s hard to look for commonalities in the
results.
 Consider consulting with an expert in questionnaire design and administration
to ensure that you ask the right questions of the right people.
 Always test a questionnaire before distributing it. It’s frustrating to discover too
late that a question was phrased ambiguously or to realize that an important
question was omitted.
 Don’t ask too many questions or people won’t respond.
Analysis 27

 Analyzing requirements involves reaching a richer and more precise

understanding of each requirement and representing sets of
requirements in multiple ways.
Following are the principal activities 28

of Analysis:
 Analyzing the information received from users to distinguish their task
goals from functional requirements, quality expectations, business rules,
suggested solutions, and other information
 Decomposing high-level requirements into an appropriate level
 Deriving functional requirements from other requirements information
 Understanding the relative importance of quality attributes
 Allocating requirements to software components defined in the system
architecture
 Negotiating implementation priorities
 Identifying gaps in requirements or unnecessary requirements as they
relate to the defined scope
System interface analysis 29

 Interface analysis is an independent elicitation technique that entails

examining the systems to which your system connects. System interface
analysis reveals functional requirements regarding the exchange of
data and services between systems.
 Identify functionality in the other system that might lead to requirements
for your system.
 These requirements could describe what data to pass to the other
system, what data is received from it, and rules about that data, such as
validation criteria.
 You might also discover existing functionality that you do not need to
implement in your system.
User interface analysis 30

 User interface (UI) analysis is an independent elicitation technique in

which you study existing systems to discover user and functional
requirements.
 It’s best to interact with the existing systems directly, but if necessary you
can use screen shots.
 User manuals for purchased packaged-software implementations often
contain screen shots that will work fine as a starting point.
Specification 31

 Requirements specification involves representing and storing the

collected requirements knowledge in a persistent and well-
organized fashion.
The principal activity is: 32

 Translating the collected user needs into written requirements and

diagrams suitable for comprehension, review, and use by their
intended audiences.
 Modeling data relationships
33
 A commonly used data model is the entity-relationship
diagram
 The data dictionary
 A data dictionary is a collection of detailed information about
the data entities used in an application.
 Collecting the information about composition, data types,
allowed values, helps developers write programs correctly,
and minimizes integration problems.
 The data dictionary complements the project glossary, which
defines application domain or business terms, abbreviations,
and acronyms.
 34

 Entries in the data dictionary can represent the following types of

data elements.
 Primitive
 A primitive data element is one for which no further decomposition is
possible or necessary.
 You can use columns in the data dictionary to describe each primitive’s
data type, length, numerical range Quantity, Quantity Units, Request ID,
and Requester Name
 Structure
 A data structure (or a record) is composed of multiple data elements.
 Structure for a chemical Tracking system can be Chemical Request,
Delivery Location, Requested Chemical, and Requester
Specifying reports 35

 Many applications generate reports from one or more

databases, files, or other information sources.
 Reports can consist of traditional tabular presentations of rows
and columns of data, charts and graphs of all types, or any
combination.
 Exploring the content and format of the reports needed is an
important aspect of requirements development.
 Report specification straddles requirements (what information
goes into the report and how it is organized) and design (what
the report should look like).
Eliciting reporting requirements 36

defining reporting requirements for an information system, consider asking

questions like the following:

 What reports do you currently use? (Some reports from an existing system, or
manually generated reports from the business, will need to be replicated in
the new system.)
 Which existing reports need to be modified? (A new or revised information
system project provides an opportunity to update reports that don’t fully
meet current needs.)
 Which reports are currently generated but are not used? (Perhaps you
don’t need to build those into the new system.)
 Can you describe any departmental, organizational, or government
standards to which reports must conform, such as to provide a consistent
look and feel or to comply with a regulation? (Obtain copies of those
standards and examples of current reports that meet them.)
Validation 37

 Requirements validation confirms that you have the correct set of

requirements information that will enable developers to build a
solution that satisfies the business objectives.
 38

 Reviewing the documented requirements to correct any problems

before the development group accepts them.
 Developing acceptance tests and criteria to confirm that a product
based on the requirements would meet customer needs and
achieve the business objectives.