2.  Software requirement engineering also called
requirement analysis bridges the gap
between system engineering and software
design.
System
Engg.
S/w req.
analysis
S/w design
Participated by both the customer and developer

3. Software requirements and analysis--
 Problem recognition
 Evaluation and synthesis
◦ focus is on what not how
 Modeling
 Specification
 Review

4.  Before requirements can be analyzed, modeled or
specified, they must be gathered through an
elicitation process.
2. Initiating the process
• The most commonly used requirement elicitation technique is
to conduct a meeting/interview.
• Participants- analyst and the customer.
• Type of question asked---
Context free, process questions, meta questions.

5. 2. Facilitated Application Specification
Technique (FAST) :
• A team oriented approach to requirement
gathering.
• Encourages creation of a joint team of
customers and developers who work together
to identify the problem, propose solution and
identify a preliminary set of requirements.

7. Basic guidelines for FAST :
• Meeting is arranged at a neutral site and attended by
both s/w engineers and customers.
• Rules for preparation and participation are established.
• Agenda is set.
• Appoint a facilitator to control the meeting (can be
developer, customer or outside expert.)
• Participants should not criticize and debate.
Goal should be to identify problems, propose solution
and identify a preliminary set of requirements

8. FAST session preparation :
• Initial meetings between customer and
developer occur where scope is established
and an overall perception of a solution is
determined.
• ½ page product request is documented .
• Meeting place, time, date for FAST are
selected and facilitator is chosen.
• Product request is distributed to all attendees
before meeting date.

9. Every FAST attendee is asked to make :
2. List of objects.
3. List of services.
4. List of constraints.
5. List of performance criteria.
Activities of FAST session.
• Each participant presents his/her list of constraints.
• Combined list is prepared eliminating redundant
entries and adding new ideas.
• List is finalized by the facilitator.

10. A microprocessor based home security system needs to be built that
would protect against a variety of undesirable situations such as
smoke, fire , illegal entry etc.
The product would use appropriate fire and smoke detectors, window
and door sensors and an alarm that would be set when an untoward
situation occurs and automatically telephone a monitoring agency.
List of objects : Fire detector, smoke detector, window and door
sensors, telephone, alarm.
List of services : setting the alarm , monitoring the sensors,
dialing the phone etc.
List of constraints : Manufacturing cost less than 80 $, must be
user friendly, must interface directly to the
standard phone line.
Performance Criteria : Sensor event should be recognized within 1
sec.

11. 3. Quality Function Deployment
This is a technique that translates the needs of the customer into
technical requirements for software.
 It emphasizes an understanding of what is valuable to the customer.
Customer satisfaction is of prime importance.
 It identifies three types of requirements
◦ Normal requirements: These requirements are the objectives
and goals stated for a software during meetings with the
customer.
Eg : For a Result management system –
Normal requirement could be-
• Merit list report
• Failed student report
• Calculation of results

12. ◦ Expected requirements: These requirements are
implicit to the software and are so fundamental that the
customer does not explicitly state them.
Eg. Usability, Reliability, ease of installation
◦ Exciting requirements: These requirements are
features that go beyond the customer's expectations
and prove to be very satisfying when present.
Eg :Sophisticated virus protection system

13. 4. Use Case
 It describes the sequence of interactions
between actors and the system necessary to
deliver the service that satisfies the goal.
How to create a use case ?
• Identify the different users (actors) of the
system.
• Create use cases which captures who (actor)
does what (interaction) without dealing with
the system internals.

16. • Used to gain a better understanding of the
problem.
• Based on constructing a partial implementation of a
system
• Prototyping can be :
4. Throwaway (Closed ended)
• Here the prototype serves only to demonstrate
requirements and is discarded after the desired
knowledge is gained.
• Since the prototype is ultimately discarded it need
not be maintainable or use efficient algorithms.

17. 2. Evolutionary (Open ended)
• Once the prototype has been used and requisite knowledge
has been gained it is eventually incorporated into the final
system.
• Must exhibit all quality attributes of the final product.
Tools used to conduct rapid prototyping :
5. Fourth generation techniques :
• 4GLs reduce programming effort, the time it takes to
develop software, and the cost of software development.
Report generators (Oracle repots,QUEST, GEMbase)
Screen generators (Oracle forms etc)
Database Query Languages (SQL, Ingres etc )
• These tools generate an executable code quickly and hence
are ideal for rapid prototyping

18. 2. Reusable software components :
• Assemble rather than build the prototype by
using a set of existing s/w components
3. Formal Specification languages:
• Replace natural language specifcation
• Eg. Set notation , algebraic notation.
• There are tools which convert these formal
language specifications into executable code.

19.  The software requirement specification is produced at the
culmination of the analysis task.
 SRS document is a contract between the development team and the
customer.
 The SRS document is known as black-box specification since the
system is considered as a black box whose internal details are not
known and only its external is visible

20. SRS

21. SRS

22. SRS

23. SRS

24. SRS

25. SRS

26. SRS

27. SRS

28. SRS

29. SRS

30.  SRS-foundation of the development stage.
 Review is conducted to ensure completeness,
accuracy and consistency in SRS.
 Avoid vague terms in SRS(usually,often)
 Once review is complete SRS is signed off by
both customer and developer.