Agility

• pervasiveness of change
• • changes in the software being built,
• • changes to the team members,
• • changes because of new technology,
• • changes of all kinds that may have an impact on the product
• they build or the project that creates the product
Agility
• Agility is effective response to change
• it enables effective communication among the stakeholders,software developers
and others involved in the project
• AGILE – to move quickly and easily
--relating to or denoting a method of project management, used especially
for software development, that is characterized by the division of tasks into
short phases of work and frequent reassessment and adaptation of plans.
• emphasize an incremental delivery strategy that gets working software to the
customer rapidly and feasible for the product type and operational environment.
Agility Cost of Change
• The conventional wisdom in software development (supported by decades of expe- rience) is that the cost of
change increases nonlinearly as a project progresses
• Agility ( “flattens” the cost of change curve (allowing a software team to accommodate changes late in a
software project without much cost and time impact.
Agile Manifesto
• Individuals and interactions over Processes and tools.
• Working software over comprehensive documentation.
• Customers are collaboration over contact negotiation.
• Responding to change over following a plan.
Advantages
• Advantages of Agile Methodology
1.Customer satisfaction is rapid, continuous development and delivery of
useful software.
2.Customer, Developer, and Product Owner interact regularly to
emphasize rather than processes and tools.
3.Product is developed fast and frequently delivered (weeks rather than
months.)
4.A face-to-face conversation is the best form of communication.
5.It continuously gave attention to technical excellence and good design.
• Disadvantages of Agile methodology:
1.It is not useful for small development projects.
2.There is a lack of intensity on necessary designing and documentation.
3.It requires an expert project member to take crucial decisions in the
meeting.
4.Cost of Agile development methodology is slightly more as compared
to other development methodology.
Agile methodology Waterfall model

It follows the incremental approach. It is a sequential design process.

It divides the project development lifecycle into a The software development process is divided into
sprint. distinct phases.

Agile methodology is a flexible methodology. The Waterfall is a structured software development

methodology.

Agile is the collection of many different projects. It is completed as one single project.

The test plan is reviewed after each sprint Test plan is reviewed after complete development.

Testing team can take part in the requirements It is difficult for the test to initiate any change in
change phase without problems. needs.
Extreme Programming (XP)?
• Extreme programming is a software development methodology that’s
part of agile methodologies.
• XP is built upon values, principles, and practices,
• its goal is to allow small to mid-sized teams to produce high-quality
software and adapt to evolving and changing requirements.
XP Values
• The XP values:
• communication
• Simplicity
• Feedback
• courage
• respect
Communication
• In order to achieve effective communication between software engineers and other
stakeholders
• XP emphasizes close, yet informal (verbal) collaboration between customers and
developers, the establishment of effective metaphors for communicating important
concepts, continuous feedback, and the avoidance of voluminous docu- mentation
as a communication medium.
• a metaphor is “a story that everyone—customers, programmers, and managers—
can tell about how the system works”
 Simplicity

To achieve simplicity, XP restricts developers to design only for immediate needs,

rather than consider future needs.
The intent is to create a simple design that can be easily implemented in code).
To improve design, it can be refactored at a later time.
Feedback
• Feedback is derived from three sources: the implemented software itself,
• the customer,
• other software team members.
• . XP makes use of the unit test as its primary testing tactic.
• As each class is developed, the team develops a unit test to exercise each
operation according to its specified functionality.
• As an increment is delivered to a customer, the user stories or use cases
that are implemented by the increment are used as a basis for acceptance
tests.
• The degree to which the software implements the output, function, and
behavior of the use case is a form of feedback.
• As new requirements are derived as part of iterative planning, the team pro-
vides the customer with rapid feedback regarding cost and schedule impact.
Courage
• There is often significant pressure to design for future
requirements.
• Most software teams believe that “designing for tomorrow” will
save time and effort in the long run.
• An agile XP team must have the courage(discipline) to design
for today, recognizing that future requirements may change
dramatically, thereby demanding substantial rework of the
design and implemented code.
Respect
• By following each of these values, the agile team inculcates
respect among its members, between other stakeholders and
team members, and indirectly, for the software itself.
• successful delivery of software increments, the team develops
growing respect for the XP process.
XP Process
• Extreme Programming encompasses a set of rules and
practices that occur within the context of four framework
activities:
• planning,
• Design
• coding,
• testing.
Planning
• begins with listening—a requirements gathering activity that enables the technical members
of the XP team to understand the business context for the software and to get a broad feel
for required output and major features and functionality.
• It leads to the creation of a set of “stories” (also called user stories) that describe required
output, features, and functionality for software to be built.
• Each story is written by the customer and is placed on an index card.
• The customer assigns a value (i.e., a priority) to the story based on the overall business
value of the feature or function.
• Members of the XP team then assess each story and assign a cost—measured in
development weeks—to it.
• If the story is esti-mated to require more than three development weeks, the customer is
asked to split the story into smaller stories and the assignment of value and cost occurs
again.
• It is important to note that new stories can be written at any time.
 Planning Contd..
• Customers and developers work together to decide how to group
stories into the next release (the next software increment) to be
developed by the XP team.
• Once a basic commitment (agreement on stories to be included,
delivery date, and other project matters) is made for a release, the
XP team orders the stories be developed.
• Stories are de- veloped in one of three ways:
• (1) all stories will be implemented immediately (within a few
weeks), (2) the stories with highest value will be moved up in the
schedule and implemented first,
• (3) the riskiest stories will be moved up in the schedule and
implemented first.
 Planning Contd:
• After the release of the first increment, project velocity is calculated
• Project Velocity is the number of customer stories implemented during the
first release.
• Project velocity can then be used to (1) help estimate delivery dates and
schedule for subsequent releases and
• (2) determine whether an overcommitment has been made for all stories
across the entire development project. If an overcommitment occurs, the
content of releases is modified or end delivery dates are changed.
• As development work proceeds, the customer can add stories, change the
value of an existing story, split stories, or eliminate them.
• The XP team then reconsiders all remaining releases and modifies its plans
accordingly.
DESIGN
• Design. XP design rigorously follows the KIS (keep it simple)
principle. A simple design is always preferred over a more complex
representation.
• In addition, the de- sign provides implementation guidance for a story
as it is written—nothing less, nothing more. The design of extra
functionality (because the developer assumes it will be required later)
is discouraged.
• CRC (class-responsibility- collaborator) cards identify and organize the object-
oriented classes7 that are rele- vant to the current software increment.
• The CRC cards are the only design work product produced as part of the XP process.
• If a difficult design problem is encountered as part of the design of a story, XP rec-
ommends the immediate creation of an operational prototype of that portion of the
design.
• Called a spike solution, the design prototype is implemented and evaluated. The
intent is to lower risk when true implementation starts and to validate the orig- inal
estimates for the story containing the design problem.
• XP encourages refactoring—a construction technique that is also a method for
design optimization. :
• Refactoring is the process of changing a software system in such a way that it does
not alter the external behavior of the code yet improves the internal structure. It is a
disci- plined way to clean up code [and modify/simplify the internal design] that
minimizes the chances of introducing bugs.
Coding
• After stories are developed and preliminary design work is done, the team does not
move to code, but rather develops a series of unit tests that will exercise each of the
stories that is to be included in the current release
• Once the unit test9 has been created, the developer is better able to focus on what must
be implemented to pass the test.
• A key concept during the coding activity (and one of the most talked about aspects of
XP) is pair programming. XP recommends that two people work together at one
computer workstation to create code for a story. This provides a mechanism for real-
time problem solving (two heads are often better than one) and real-time quality
assurance (the code is reviewed as it is created). It also keeps the developers focused
on the problem at hand
• As pair programmers complete their work, the code they develop is integrated with the
work of others.
 Testing
• The unit tests that are created should be implemented using a framework
• As the individual unit tests are organized into a “universal testing suite”
• integration and validation testing of the system can occur on a daily basis. This pro-vides the XP team with a
continual indication of progress and also can raise warning flags.
• XP acceptance tests, also called customer tests, are specified by the customer and focus on overall system
features and functionality that are visible and reviewable by the customer
Other Agile Process Models

• Many agile process models have been proposed and are in use across the industry.
Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature Drive Development (FDD) • Lean Software Development (LSD) • Agile Modeling (AM)
• Agile Unified Process (AUP)
 SCRUM
• Scrum (the name is derived from an activity that occurs during a rugby match) is an agile software
development method that was conceived by Jeff Sutherland and his development team in the early
1990s.
• Framework activities: requirements, analysis, design, evolution, and delivery.
• Each framework activity, has work tasks occur within a process pattern called a sprint.
• The work conducted within a sprint is adapted to the problem and is defined and often modified in real
time by the Scrum team
• Scrum incorporates a set of process patterns that emphasize project priorities, compartmentalized
work units, communication, and frequent customer feedback.
• Scrum is light-weighted framework
• Scrum emphasizes self-organization
• Scrum is simple to understand
• Scrum framework help the team to work together
Key points on Scrum
• Scrum emphasizes transparency, inspection, and adaptation.
• The product is built incrementally in fixed-length iterations (sprints).
• Changes are only made between sprints unless there is a compelling
reason to make a change during a sprint.
• Scrum provides a flexible and collaborative approach to project
management, allowing teams to adapt to changing requirements and
deliver a potentially shippable product at the end of each sprint.
• It is widely used in various industries for its focus on iterative
development, continuous improvement, and customer feedback.
Lifecycle of Scrum
• Each of these process patterns defines a set of development actions:
• Backlog—a prioritized list of project requirements or features that provide busi- ness value for the
customer. Items can be added to the backlog at any time.
• The product manager assesses the backlog and updates priorities as required.
• Sprints—consist of work units that are required to achieve a requirement de- fined in the backlog
that must be fit into a predefined time-box
• Changes (e.g., backlog work items) are not introduced during the sprint
• Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team. Three
key questions are asked and answered by all team members
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
• A team leader, called a Scrum master, leads the meeting and assesses the responses from each
person. The Scrum meeting helps the team to uncover potential problems as early as possible.
• Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer
Scrum Events
• Sprint: A time-boxed iteration (usually 2-4 weeks) during which
a potentially shippable product increment is created.
• Sprint Planning: A meeting at the beginning of each sprint where
the team plans the work to be done.
• Daily Scrum (Stand-up): A short daily meeting where team
members discuss progress, plan for the day, and identify and
address impediments.
• Sprint Review: The Sprint Review is held at the end of each sprint.
The Scrum Team, stakeholders, and the Product Owner come together
to review the completed work. The Development Team demonstrates
the product increment, and stakeholders provide feedback. This
session informs future planning and adjustments to the Product
Backlog.
• Sprint retrospective: The Sprint Retrospective occurs after the Sprint
Review and involves the Scrum Team reflecting on the previous
sprint. The team discusses what went well, what could be improved,
and any action items for enhancing their processes. The focus is on
continuous improvement.
• Advantage of using Scrum framework:
• Scrum framework is fast moving and money efficient.
• Scrum framework works by dividing the large product into small sub-products. It’s
like a divide and conquer strategy
• In Scrum customer satisfaction is very important.
• Scrum is adaptive in nature because it have short sprint.
• Disadvantage of using Scrum framework:
• Scrum framework do not allow changes into their sprint.
• Scrum framework is not fully described model. If you wanna adopt it you need to
fill in the framework with your own details like Extreme Programming(XP),
Kanban, DSDM.
• It can be difficult for the Scrum to plan, structure and organize a project that lacks
a clear definition.
• The daily Scrum meetings and frequent reviews require substantial resources.
 Requirement Engineering
• The broad spectrum of tasks and techniques that lead to an understanding of re- quirements is
called requirements engineering.
• From a 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.
• Requirements engineering provides the appropriate mechanism for understand- ing what the
customer wants, analyzing need, assessing feasibility, negotiating a rea- sonable solution,
specifying the solution unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational .
• It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation,
specification, validation, and management. It is important to note that some of these tasks
occur in parallel and all are adapted to the needs of the project.
• Requirements engineering provides the appropriate mechanism for
understand- ing
• what the customer wants,
• analyzing need,
• assessing feasibility,
• negotiating a rea- sonable solution,
• specifying the solution unambiguously,
• validating the specification,
• and managing the requirements as they are transformed into an operational .
Requirement Engineering Task/Stages
• It encompasses seven distinct tasks:
• Inception,
• Elicitation,
• Elaboration,
• Negotiation,
• Specification,
• Validation.
• Management.
• It is important to note that some of these tasks occur in parallel and all
are adapted to the needs of the project.
Inception
• How does a software project get started?
• Is there a single event that becomes the catalyst for a new
computer-based system or product, or does the need evolve
over time?
INCEPTION
• most projects begin when a business need is identified or a potential new market
or service is discovered.
• Stakeholders from the business community (e.g., business managers, marketing
people, product managers) define a business case for the idea, try to identify the
breadth and depth of the market, do a rough feasibility analysis, and identify a
working description of the project’s scope.
• This phase helps to understand a basic understanding of the
problem, the people who want a solution, the nature of the
solution that is desired, and the effective- ness of preliminary
communication and collaboration between the other stakeholders
and the software team.
 Elicitation
• ask the customer, the users, and others what the objectives for the system or product are, what is to be
accomplished, how the system or product fits into the needs of the business, and finally, how the sys- tem
or product is to be used on a day-to-day basis.
• a collaborative, team-oriented approach to requirements gathering, stakeholders work together to identify
the problem, propose elements of the solution, negotiate different approaches and specify a preliminary
set of solution requirements
• Collaborative Requirements Gathering
• Meetings are conducted and attended by both software engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points
• but informal enough to encourage the free flow of ideas.
• A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic
bulletin board, chat room, or virtual forum) is used.
• each attendee is asked to make a list of objects that are part of the environment that surrounds the
system, other objects that are to be produced by the system, and objects that are used by the
system to perform its functions.
• In addition, each attendee is asked to make another list of services (processes or functions) that
manipulate or in- teract with the objects.
• Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria (e.g., speed,
accuracy) are also developed.
 Quality Function Deployment
• Quality function deployment (QFD) is a quality management technique that translates
the needs of the customer into technical requirements for software.
• QFD “concen- trates on maximizing customer satisfaction from the software
engineering process”
• QFD identifies three types of requirements
• Normal requirements. The objectives and goals that are stated for a prod-uct or
system during meetings with the customer. If these requirements are present, the
customer is satisfied. Examples of normal requirements might be requested types of
graphical displays, specific system functions, and defined levels of performance.
• Expected requirements. These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them. Their
absence will be a cause for significant dissatisfaction. Examples of expected
requirements are: ease of human/machine interaction, overall operational correctness
and reliability, and ease of software installation.
• Exciting requirements. These features go beyond the customer’s expecta- tions
and prove to be very satisfying when present. For example, software for a new
mobile phone comes with standard features, but is coupled with a set of
unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight
every user of the product.

• QFD uses customer interviews and observation, surveys, and examination of

historical data (e.g., problem reports) as raw data for the requirements gathering
activity.
• These data are then translated into a table of requirements—called the customer
voice table—that is reviewed with the customer and other stakeholders.
• A variety of diagrams, matrices, and evaluation methods are then used to
extract expected re- quirements and to attempt to derive exciting requirements
USAGE SCENARIOS
• As requirements are gathered, an overall vision of system functions and features
be- gins to materialize. However, it is difficult to move into more technical
software en- gineering activities until you understand how these functions and
features will be used by different classes of end users.
• To accomplish this, developers and users can create a set of scenarios that
identify a thread of usage for the system to be con- structed. The scenarios, often
called use cases
 Elicitation Work Products

• The work products produced as a consequence of requirements elicitation will vary

depending on the size of the system or product to be built. For most systems, the work
products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements
elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain
• constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under
different operating conditions.
• Any prototypes developed to better define requirements.
Ellaboration
• The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration. This task focuses on devel- oping a
refined requirements model .hat identifies various aspects of software function,
behavior, and information.
• Elaboration is driven by the creation and refinement of user scenarios that de-
scribe how the end user (and other actors) will interact with the system.
• The attributes of each analysis class are defined, and the serv- ices4 that are
required by each class are identified. The relationships and collabora- tion
between classes are identified, and a variety of supplementary diagrams are
produced.
Negotiation.
• Customers and users ask for more than can be achieved, given limited business
resources. It’s also relatively common for different customers or users to propose
conflicting requirements, arguing that their version is “essential for our special
needs.”
• You have to reconcile these conflicts through a process of negotiation.
• Customers, users, and other stakeholders are asked to rank requirements and then
discuss con- flicts in priority.
• Using an iterative approach that prioritizes requirements, assesses their cost and
risk, and addresses internal conflicts, requirements are eliminated, combined,
and/or modified so that each party achieves some measure of satisfaction.
• Stakeholders are asked to balance functionality, performance, and other prod- uct or
system characteristics against cost and time-to-market.
• The best negotiations strive for a “win-win” result
• That is, stakeholders win by getting the system or product that satisfies the majority of
their needs and you (as a member of the software team) win by working to realistic and
achievable budgets and deadlines.
• Rather than a single customer communication activity, the following activities are
defined:
• 1. Identification of the system or subsystem’s key stakeholders.
• 2. Determination of the stakeholders’ “win conditions.”
• 3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-
win conditions for all concerned (including the software team).
Specification
• A specification can be a writ- ten document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype, or any
combination of these.
• For large sys- tems, a written document, combining natural language descriptions
and graphical models may be the best approach.
• Usage scenarios are all that is re- quired for smaller products or systems that
reside within well-understood technical environments.
Validation
• The work products produced as a consequence of requirements engi-
neering are assessed for quality during a validation step.
• Requirements validation examines the specification5 to ensure that all
software requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and
corrected; and that the work products conform to the standards estab-
lished for the process, the project, and the product.
Validating the requirements
• A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappro- priate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be
essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
• specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of
• the system to be built?
• Has the requirements model been “partitioned” in a way that exposes
• progressively more detailed information about the system?
• Have requirements patterns been used to simplify the requirements model? Have
all patterns been properly validated? Are all patterns consistent with customer
requirements?
Requirements management.
• Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system.
• 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.
Establishing GroundWork
• Steps required to establish the ground- work for an understanding of software
requirements—to get the project started in a way that will keep it moving forward
toward a successful solution.
• Identifying Stakeholders
Stakeholder -define a stakeholder as “anyone who benefits in a direct or
indirect way from the system which is being developed.”
• At inception, you should create a list of people who will contribute input as re-
quirements are elicited The initial list will grow as stakeholders are contacted
• Each stakeholder has a different view of the system, achieves different
benefits when the system is successfully developed, and is open to different
risks if the development effort should fail.
• Recognizing Multiple Viewpoints

• Because many different stakeholders exist, the requirements of the system will be
explored from many different points of view.
• For example, the marketing group is in- terested in functions and features that will excite
the potential market, making the new system easy to sell.
• Business managers are interested in a feature set that can be built within budget and that
will be ready to meet defined market windows.
• Each of the stakeholders needs will contribute information to the requirements
engineering process.
• As information from multiple viewpoints is col- lected, emerging requirements may be
inconsistent or may conflict with one another.
• The team should be able to categorize all stakeholder information (including inconsistent
and conflicting requirements) in a way that will allow decision makers to choose an
internally consistent set of requirements for the system.
• Working toward Collaboration
• Customers (and other stakeholders) must collaborate among them-selves and with
software engineering practitioners for a successful system.
• The job of a requirements engineer is to identify areas of commonality (i.e., re-
quirements on which all stakeholders agree) and areas of conflict or inconsistency
(i.e., requirements that are desired by one stakeholder but conflict with the needs of
another stakeholder
• stakeholders collaborate by providing their view of requirements, but a strong
“project champion”(e.g., a business manager or a senior technologist) may make the
final decision about which requirements to be finalised.
• Asking the First Questions
• The first set of context-free questions focuses on the customer and other stakeholders, the
overall project goals and benefits. For example, you might ask:
• • Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution? • Is there another source for the
solution that you need?
• These questions help to identify all stakeholders who will have interest in the software to be built.

• The next set of questions enables you to gain a better understanding of the prob- lem and allows
the customer to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the
• solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?
• The final set of questions focuses on the effectiveness of the communication
activity itself.
• Are you the right person to answer these questions? Are your answers “official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
• These questions (and others) will help to “break the ice” and initiate the communi-
cation that is essential to successful elicitation.
Developing USE CASES
• a use case tells a story about how an end user (playing one of a number of possible
roles) interacts with the system under a specific set of circumstances.
• The story may be narrative text, an outline of tasks or interactions, a template-
based description, or a diagrammatic representation.
• Regardless of its form, a use case depicts the software or system from the end
user’s point of view.
• The first step in writing a use case is to define the set of “actors” that will be
involved in the story.
• Actors are the different people (or devices) that use the system or product within
the context of the function and behavior that is to be described. Actors represent
the roles that people (or devices) play as the system operates.
• It is important to note that an actor and an end user are not
the same.
• A typical user may play a number of different roles when
using a system, whereas an actor represents a class of
external entities (often, but not always, people) that play
just one role in the context of the use case.
• Primary actors interact to achieve required system function and derive the intended benefit from the system.
They work directly and frequently with the software.
• Secondary actors support the system so that primary actors can do their work
• Once actors have been identified, use cases can be developed. a number of
questions, that should be answered by a use case:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
Building Requirement Model
• The intent of the analysis model is to provide a description of the required informational,
functional, and behavioral domains for a computer-based system.
• The model changes dynamically as you learn more about the system to be built, and other
stakeholders un- derstand more about what they really require.
• As the requirements model evolves, certain elements will become relatively stable, providing a solid
foundation for the design tasks that follow.
• Elements of the Requirements Model
• Scenario based elements
• Class based elements
• Behavior Elements
• Flow oriented elements.
Elements of the Requirements Model

• Scenario-based elements. The system is described from the user’s point of view
using a scenario-based approach.
• Scenario-based elements of the requirements model are often the first part of the
model that is developed.
• Scenarios are created by using
• Use case Diagram,
• Activity Diagram
• User Stories
Use case Diagram

• It is used to represent the dynamic

behavior of a system.
• Actors
• Use cases
• Communication Link
• System Boudary
Activity Diagram

• Helps to predict the workflow from one

activity to another.
• Show the condition of flow and the
order in which it occurs.
Class based elements
• Represents the classes, object, attributes & operations of system.
• 1. Class Diagram
• The class diagram shows a static view of an application.
• It represents the types of objects residing in the system and the relationship
between them.
• It describes the major responsibilities of a system.
 Flow oriented Elements
• It shows how data objects are
transformed by processing the
function.
• Data Flow Diagram
• It is a graphical representation of
flow of data in an information
system
• It is capable of depicting incoming
data flow ,outgoing data flow and
stored data
• Control Flow Diagram
• Graphical representation of control flow or computation during the
execution of programs or applications.
• Used in static analysis as well as compiler applications.
• Accurately shows the flow inside a program unit.

• Entry Block: Allows the control into the control flow graph
• Exit block:control flow leaves through the exit block.
Behavioral Elements
• It helps to understand the overall behavior and factors that influence
the behavior of a system.
• 1.State Transition Diagram
Overall states of system
Events which are responsible for a change in state of a system.