Unit - II

Software Requirement Engineering

Core Principles of Software Engineering

 The First Principle: The Reason It All Exists

 A software system exists for one reason: to provide value to its users. All decisions should be
made with this in mind.
 Before specifying a system requirement, system functionality, before determining the
hardware platforms, first determine, whether it adds value to the system.

 The Second Principle: KISS (Keep It Simple, Stupid!)

 All design should be as simple as possible, but no simpler. This facilitates having a more easily
understood and easily maintained system.
 It doesn’t mean that features should be discarded in the name of simplicity.
 Simple also does not mean “quick and dirty.” In fact, it often takes a lot of thought and work
over multiple iterations to simplify.

 The Third Principle: Maintain the Vision

 A clear vision is necessary to the success of a software project.

 If you make compromise in the architectural vision of a software system, it will weaken and will
eventually break.
 Having a powerful architect who can hold the vision helps to ensure a very successful software
project.

 The Fourth Principle: What You Produce, Others Will Consume

 Always specify, design, and implement by keeping in mind that someone else will have to
understand what you are doing.
 Design (make design), keeping the implementers (programmers) in mind.
 Code (program) with keeping in mind those who will maintain and extend the system.
 Someone may have to debug the code you write, and that makes them a user of your code.

 The Fifth Principle: Be Open to the Future

 A system with a long lifetime has more value.

 In today's computing environments, where specifications change on a moment's notice and
hardware platforms are obsolete when just a few months old, software lifetimes are typically
measured in months instead of years.
 True “industrial-strength” software systems must last for longer.
 To do this successfully, these systems must be ready to adapt changes.
  Always ask “what if,” and prepare for all possible answers by creating systems that solve the general
problem, not just the specific one.

 The Sixth Principle: Plan Ahead for Reuse

 Reuse saves time and effort.

 The reuse of code and designs has a major benefit of using object-oriented technologies.
 Planning ahead for reuse reduces the cost and increases the value of both the reusable components
and the systems into which they are incorporated.

 The Seventh principle: Think!

 Placing clear, complete thought before action almost always produces better results.
 When you think about something, you are more likely to do it right. You also gain knowledge about
how to do it right again.
 If you do think about something and still do it wrong, it becomes a valuable experience.

Software Engineering Practices

 Communication Principles
Software requirement always begins with communication between two or more parties.
In communication principles, the initial stage is to collect or gather requirement from customer.

Principle 1 Listen:

 Try to focus on the speaker‘s words, rather than formulating your response to those words.
 Ask for clarification if something is unclear, but avoid constant interruptions.
 Never become contentious in your words or actions (e.g., rolling your eyes or shaking your head)
as a person is talking.

Principle 2 Be prepared before you communicate:

 Spend the time to understand the problem before you meet with others. If necessary, perform
some research to understand business domain.
 If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.
 Agenda contains the points to be discussed in the meeting

Principle 3:- Someone should facilitate the activity

Every communication meeting should have a leader (a facilitator)

 To keep the conversation moving in a productive direction,

 To mediate any conflict that does occur, and
 To ensure that other principles are followed.

Principle 4 Face-to-face communication is best:

 It usually works better when some other representation of the relevant information is present.
 For example, a participant may create a drawing /document that serve as a focus for discussion.

Principle 5 Take notes and document decisions:

Someone participating in the communication should serve as a recorder and write down all
important points and decisions.

Principle 6 Strive for collaboration:

 For better team work, collaboration in team member is essential.

 Collaboration occurs when the collective knowledge of members of the team is used to describe
product or system functions or features.
  Each small collaborations builds trust among team members and creates a common goal for the
team.

Principle 7 Stay focused; modularize your discussion:

 The more people involved in any communication, the more likely that discussion will bounce from
one topic to the next.
 The facilitator should keep the conversation modular; leaving one topic only after it has been
resolved.

Principle 8 If something is unclear, draw a picture:

 Sometimes, only verbal communication is not good enough.

 A sketch or drawing can often provide clarity when words fail to do the job.

Principle 9 Keep the discussion to move on

 Once you agree to something, move on.

 If you can’t agree to something, move on.
 If a feature or function is unclear and cannot be clarified at the moment, move on.
The people who participate in communication should recognize that many topics require
discussion and that moving on is sometimes the best way to achieve communication agility.

Principle 10 Negotiation is successful when both parties agree.

 There are many instances in which you and other stakeholders must negotiate functions and
features, priorities, and delivery dates.
 If the team has collaborated well, all parties have a common goal. Still, negotiation will demand
compromise from all parties.

Planning Practices

Planning activity establishes a plan for software engineering work.

Planning describes the technical tasks to be conducted, the resources that will be required, and the
risks that are likely to be produced.
Principle 1: Understand the scope of the project.

It’s impossible to use a road map if you don’t know where you’re going.
Scope provides the software team with a destination.

Principle 2: Involve stakeholders in the planning activity.

Stakeholders define priorities and establish project constraints.

To accommodate these realities, software engineers must often negotiate order of delivery, time lines,
and other project-related issues.

Principle 3: Recognize that planning is iterative.

As work begins, it is very likely that things will change.

As a consequence, the plan must be adjusted to accommodate these changes.
In addition, iterative, incremental process models dictate replanning after the delivery of each
software increment based on feedback received from users.

Principle 4: Estimate based on what you know.

The intent of estimation is to provide an indication of effort, cost, and task duration, based on the
team’s current understanding of the work to be done.
If information is unreliable, estimates will be equally unreliable.

Principle 5: Consider risk as you define the plan.

If you have identified risks that have high impact and high probability, contingency planning is
necessary.
In addition, the project plan (including the schedule) should be adjusted to accommodate the thought
that one or more of these risks will occur.

Principle 6: Be realistic.
People don’t work 100 percent of every day.
Noise always enters into any human communication.
Omissions and ambiguity are facts of life.
Change will occur.
Even the best software engineers make mistakes.
These and other realities should be considered as a project plan is established.

Principle 7: Adjust granularity as you define the plan.

Granularity refers to the level of detail that is introduced as a project plan is developed.
A “high-granularity” plan provides significant work task detail that is planned over short time
increments.
A “low-granularity” plan provides broader work tasks that are planned over longer time periods.

Principle 8: Define how you are going to achieve quality.

The plan should identify how the software team intends to ensure quality.
If technical reviews are to be conducted, they should be scheduled.
If pair programming is to be used during construction, it should be explicitly defined within the plan.

Principle 9: Describe how you aim to accommodate change.

You should identify how changes are to be accommodated as software engineering work proceeds.
For example, can the customer request a change at any time?
If a change is requested, is the team ready enough to implement it immediately?
How is the impact and cost of the change assessed?

Principle 10: Always track the plan and make adjustments as required.
Software projects fall behind schedule one day at a time.
Therefore, it makes sense to track progress on a daily basis, looking for problem areas and situations
in which scheduled work does not conform to actual work conducted.

Modeling Practices
 Modeling activity encompasses the creation of models that allow the developer & the customer to
to gain a better understanding of the actual entity to be built.
 When entity to be built is software, our model must take a different form.
 It must be capable of representing the
- information that software transforms,
- the architecture and functions that enable the transformation to occur,
 - the features that user desire, and
- the behavior of the system as the transformation is taking place.
 In software engineering work, two classes of models can be created:
 Requirements (Analysis) models and
 Design models.

 Analysis Modeling Principles

Requirements models (also called analysis models) represent customer requirements by
depicting the software in three different domains:

 The information domain,

 The functional domain, and
 The behavioral domain.

Principle 1: The information domain of a problem must be represented and understood.

Analysis model uses “data flow diagram“ to show information domain which includes following
detail:-

 the data that flow into the system,

 the data that flow out of the system, and
 the data stores that collect and organize persistent data objects.

Principle 2: The functions that the software performs must be defined.

Software functions provide benefit to end users.

Function are process those transform input flow to output flow.
Identify functions that transform data objects.

Principle 3: The behavior of the software (as a consequence of external events) must be
defined clearly.

Analysis Model
– indicate different states of the system
– specify events that cause the system to change state
Analysis model uses state transition diagram to represent the behavior of system clearly.

Principle 4: The clear hierarchy among information, function and behavior must be shown.

Information, function and behavior of system must be represented by using proper hierarchy which
leads to easy design.

Principle 5: Analysis should be clear enough to convert it into design model.

Requirement modeling begins by describing the problem from the end-user’s perspective.
If analysis of requirement is clear and simple then it will be easy for design.

Design Modeling Principles

Design models represent characteristics of the software that help practitioners to construct it
effectively:

 The architecture,
 The user interface, and
 The component-level detail.

Principle 1: Design should be traceable from analysis model.

 The analysis model describes the information, functions, and behavior of the system.
 The design model translates all these things into architecture: a set of subsystems that implement
major functions, and a set of component level designs.
 This implies that design model must be traceable from the analysis model.

Principle 2: Consider the architecture of the system to be built.

 Software architecture is a skeleton of the system to be built.

It affects interfaces, data structures, program control flow and behavior, the manner in which
testing can be conducted, the maintainability of the resultant system and much more.
 For all these reasons, design should start with architectural considerations.

Principle 3: Design of data is as important as design of processing functions.

Data design encompasses the manner in which the data objects are realized within the design.

It helps to simplify the program flow, makes the design and implementation of the software
components easier, and makes overall processing more efficient.

Principle 4: Interfaces (both internal and external) must be designed with care.

The data flow between components decides the processing efficiency, error flow, and design
simplicity.
A well-designed interface makes integration easier and tester can validate the component functions
more easily.

Principle 5: User interface design must satisfy all the needs of the end user.
The user interface is the main thing of any software. No matter how good its internal functions are
or how well designed its architecture is but if the user interface is poor and end-users don’t feel ease
to handle the software then it leads to the opinion that the software is bad.

Principle 6: Component-level design should be functionally independent.

The functionality that is delivered by a component should be cohesive – that is it should focus on one
and only one function or sub –function

Principle 7: Components should be loosely coupled to one another and to the external
environment.

Principle 8: Design representations (models) should be easily understandable.

Principle 9: The design should be developed iteratively.

Construction Principles
The construction activity encompasses a set of coding and testing tasks that lead to operational
software that is ready for delivery to the customer or end user.

 Preparation Principles
 Understand the problem you’re trying to solve.
 Understand basic design principles and concepts.
 Pick a programming language that meets the needs of the software to be built and the environment
in which it will operate.
 Select a programming environment that provides tools that will make your work easier. (E.g. TC,
JRE etc.).
 Create a set of unit tests that will be applied once the component you code is completed.
  Actual Coding Principles:
1. Construct your algorithms by following structured programming practice.
2. Consider the use of pair programming.
3. Select data structures that will meet the needs of the design.
4. Understand the software architecture and create interfaces that are consistent with it.
5. Keep conditional logic as simple as possible.
6. Create nested loops in a way that makes them easily testable.
7. Select meaningful variable names and follow other local coding standards.
8. Write code that is self-documenting. (e.g. Comments)
9. Create a visual layout (e.g., indentation and blank lines) that aids understanding.

Validation Principles:
After you’ve completed your first coding pass, be sure you
 Conduct a code walkthrough when appropriate.
 Perform unit tests and correct errors you’ve uncovered.
 Refactor the code.

 Testing Principles
Testing objectives:

 Testing is a process of executing a program with the intention of finding an error.

 A good test case is one that has a high probability of finding an undiscovered error.
 A successful test is one that uncovers an undiscovered error.

Levels of Testing:

The initial focus of testing is at the component level, often called unit testing.
The other levels of testing include:

1. Integration Testing (conducted as the system is constructed).

2. Validation Testing (assesses whether requirements have been met for the complete system or
software increment).
3. Acceptance Testing (conducted by the customer in an effort to check all required features
and functions)

Principle 1: All tests should be traceable to customer requirements.

 The objective of software testing is to uncover errors.

 The most severe defects (from the customer’s point of view) are those that cause the program to
fail to meet its requirements.
Principle 2: Tests should be planned long before testing begins. (Early Testing )

 Test planning can begin as soon as the requirements model is complete.

 Detailed definition of test cases can begin as soon as the design model has been made.
 Therefore, all tests can be planned and designed before any code has been generated.
 It is always better to identify defects at the early stages rather than that at the end.
 The cost of fixing the defects are more at the later stages of SDLC.

Principle 3: The Pareto principle applies to software testing.

 The Pareto Principle for software testing states that 80% of software defects come from 20% of
program components.
 The problem, of course, is to isolate these suspect components and to thoroughly test them.

Principle 4: Testing should begin “in the small” and progress toward testing “in the large.”

 The first tests planned and executed generally focus on individual components.
 As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components
and ultimately in the entire system.

Principle 5: Exhaustive testing is not possible.

 It is the process of testing the functionality of the software in all possible inputs (valid or invalid)
and pre-conditions is known as exhaustive testing.
 Exhaustive testing is impossible means the software can never test at every test case.
 It can test only some test cases and assume that the software is correct and it will produce the
correct output in every test case. If the software will test every test case then it will take more cost,
effort, etc., which is impractical.

Principle 6: Testing shows the presence of defects.

The goal of software testing is to make the software fail.

Software testing reduces the presence of defects.
Software testing talks about the and doesn't talk about the absence of defects.
Software Deployment
 Concept of Delivery Cycle, Support Cycle & feedback Cycle:
 The deployment activity encompasses three actions: delivery, support, and feedback.
 Because modern software process models are evolutionary or incremental in nature, deployment
happens not once, but a number of times as software move toward completion.
 Each delivery cycle provides the customer and end users with an operational software increment
that provides usable functions and features.
 Each support cycle provides documentation and human assistance for all functions and features
introduced during all deployment cycles to date.
 Each feedback cycle provides the software team with important guidance that result in
modifications to the functions, features, and approach taken for the next increment.

Deployment Principles:
Principle 1: Manage customer’s expectations.

It always happens that customer wants more than he has started earlier as his requirements.

It may be the case that customer gets disappointed, even after getting all his requirements satisfied.

Hence at time of delivery, developer must have skills to manage customer‘s expectations.

Principle 2: Assembly and test complete delivery package.

It is not the case that the deliverable package is “only software.”

The customer must get all supporting and essential help from developer‘s side.

All installation scripts and other operational features should be thoroughly tested.

Principle 3: Record-keeping mechanism must be established for customer support.

Customer support is important factor in deployment phase.

If proper support is not provided, customer will not be satisfied.

Hence support should be well planned and record-keeping mechanism must be established for
customer support.
Principle 4: Provide essential instructions, documentations and manual.

Many times, developer thinks ―when project is successful, deliverable part is only working program.
But realty is that working program is just part of software product.

Actual project delivery includes all documentations, help files and guidance(training) for handling
the software by user.

Principle 5: Don’t deliver any defective or buggy software to the customer.

Under time pressure, some software organizations deliver low-quality increments with a warning to
the customer that “bugs will be fixed in the next release.” Customer gets disappointed by this.

Hence it is necessary to fix the bug before the product is delivered to the customer.
Requirements Engineering
What is requirement engg. ? What is its need? What are different subtasks included in it?

From software process perspective, requirements engineering is a major software engineering

action that begins during the communication activity and continues into the modeling activity.
It must be adapted to the needs of the process, the project, the product, and the people doing the
work.

 Need of Requirement Engineering:-

Requirements engineering tools assist in requirements gathering, requirements modeling,
requirements management, and requirements validation.

 Requirement Engineering Tasks

 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements management

1. Inception
 In Requirement Engineering, inception is the initial task focused on understanding the
problem and establishing the scope of the project.
 In this phase, the question why you want to do this will be answered.

During inception, the requirements engineer asks a set of questions to establish…

 Basic Understanding of the problem.

 The people who want a solution.
 Nature of the solution.
 Communication and collaboration between the customer and developer.

2. Elicitation
 Elicitation means to define what is required.
Requirement engineer asks the customer, user and others:

1) what are the objectives for the system or product

2) what is to be accomplished
3) how the system or product fits into the needs of the business,
4) how the system or product is to be used on a day-to-day basis

The following problems can occur in the elicitation phase:

 Problem of Scope:
The requirements given are of unnecessary detail, ill-defined, or not possible to implement.

 Problem of Understanding:
Not having a clear-cut understanding between the developer and customer when putting out the
requirements needed.
Sometimes the customer might not know what they want or the developer might misunderstand
one requirement for another.

 Problem of Volatility:
Requirements changing over time can cause difficulty in leading a project.
It can lead to loss and wastage of resources and time.

3. Elaboration
 The information obtained from the customer during inception and elicitation is expanded and
refined during elaboration.
 This task focuses on developing a refined requirements model (like use case diagrams, class
diagrams) that identifies various aspects of software function, behavior, and information.
 It describe how the end user will interact with the system.
 It describes business domain entities that are visible to the end user.
 The relationships between classes are identified, and a various supplementary diagrams are
produced.

4. Negotiation
 In this phase developer and the customer discussess on what is needed and what is to be
eliminated.
 Customers, users, and other stakeholders are asked to rank requirements and then discuss
conflicts in priority.
 Risks associated with each requirement are identified and analyzed.
 Rough estimates of development effort are made and are used to assess the impact of each
requirement on project cost and delivery time.
 Using an iterative approach, requirements are eliminated, combined, and/or modified so that
each party gets satisfaction.

5. Specification
 A specification can be a written document, a set of graphical models, a formal mathematical model,
and a collection of usage scenarios, a prototype, or any combination of these.
 Specification is the final work product produced by the requirement engineer.
 It is in the form of software requirement specification(SRS).
 The format of a specification varies with the size and the complexity of the software to be built
6. Validation
 During a validation step, documented SRS (software requirement specification) will be examined
by conducting technical reviews
 The review team that validates requirements includes software engineers, customers, users, and
other stakeholders.
 They examine the specification to check errors in content or interpretation, areas where
clarification may be required, missing information, inconsistencies, conflicting requirements, or
unrealistic (unachievable) requirements.

7. Requirements management

 Requirements management is a set of activities that help the project team identify, control, and
track requirements and changes to requirements at any time as the project proceeds.
TYPES OF REQUIREMENTS
1. Functional Requirements
Functional requirements describe what the software should do.
They describe the specific features and functions that the software or system should provide to the users.

Examples:
User Authentication: The system must allow users to log in using a username and password.
Search Functionality: The software should enable users to search for products by name or category.
Report Generation: The system should be able to generate sales reports for a specified date range.

2. Product Requirements(Non Functional Requirements):

Product Requirements define the characteristics and attributes of the product being developed.
They describe how the software performs a task rather than what it should do.
They focus on overall quality attributes of product such as reliability, usability, portability, efficiency,
performance, response time, etc

Examples:
Performance: The system should process 1,000 transactions per second.
Usability: The software should be easy to use and have a user-friendly interface.
Reliability: The product should be reliable and have a low failure rate.
Security: Data must be encrypted during transmission and storage.

3. Organizational Requirements:
These requirements are related to the policies and procedures of the organization developing or using
the product.
They may include factors like budget, timelines, available resources, organizational policies.

Examples:
The project must be completed within a budget of $10,000.
The system must be compatible with existing infrastructure.
The development team must follow specific coding standards.

4. External Requirements:
These are requirements imposed by external factors, such as regulations, standards, or the environment
in which the product will operate.

Examples:
The system must comply with GDPR regulations.
The product must be compatible with a specific operating system.
Software should operates within legal jurisdiction. For eg. Pirated software should not be sold.