lOMoARcPSD|44045213

Unit-2 Notes

COMPUTER SCIENCE ENGINEERING (Jawaharlal Nehru Technological University,

Kakinada)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Chetan M ([email protected])
 lOMoARcPSD|44045213

UNIT-2

Topics:

Agility,
Agility and the Cost of Change,
Agile Process,
Extreme Programming (XP),
Other Agile Process Models,
A Tool Set for the Agile Process,
Software Engineering Knowledge,
Core Principles,
Principles That Guide Each Framework Activity

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 AGILITY:
Agile Software Development is a lightweight software engineering framework that promotes iterative
development throughout the life-cycle of the project .Agility means effective (rapid and adaptive) response
to change by having effective communication among all stockholder.
Agile software engineering combines a philosophy and a set of development guidelines. The
philosophy encourages customer satisfaction and early incremental delivery of software; small, highly
motivated project teams; informal methods; minimal software engineering work products; and overall
development simplicity. The development guidelines stress delivery over analysis and design (although these
activities are not discouraged), and active and continuous communication between developers and customers.

 AGILITY AND THE COST OF CHANGE:

Conventional wisdom is that the cost of change increases nonlinearly as a project progresses.
It is relatively easy to accommodate a change when a team is gathering requirements early in a project. If
there are any changes, the costs of doing this work are minimal. But if the middle of validation testing, a
stakeholder is requesting a major functional change. Then the change requires a modification to the
architectural design, construction of new components, changes to other existing components, new testing and
so on. Costs escalate quickly.

On the other hand a well-designed agile process may “flatten” the cost of change curve by coupling
incremental delivery with agile practices such as continuous unit testing and pair programming. Thus
team can accommodate changes late in the software project without dramatic cost and time impact.
When incremental delivery is coupled with other agile practices such as continuous unit testing and pair
programming , the cost of making a change is attenuated.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 AGILE PROCESS:
"Agile Process Model" refers to a software development approach based on iterative development. Agile
methods break tasks into smaller iterations, or parts do not directly involve long term planning. The
project scope and requirements are laid down at the beginning of the development process. Plans
regarding the number of iterations, the duration and the scope of each iteration are clearly defined in
advance. An agile process must be adaptable.
Requires customer feedback. Analysis, design, construction and testing are not predictable and thus
has to adapt as changes occur due to unpredictability and Delivers multiple ‘software increments’, deliver
an operational prototype or portion of an operational system to collect customer feedback for adaption.

a) Agility principles (12 principles )

b) The politics of Agile Development
c) Human factors
a) Agility principles:
The Agile Alliance defines 12 agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team
is face to face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

b) The politics of Agile Development:

There is consider able debate about the benefits and applicability of agile software development
as opposed to more conventional software engineering process.Traditional methodologists are a
bunch of stick-in-the- mud s who’d rather produce flawless documentation than a working
system that meets business needs.

c) Human factors
The process molds to the needs of the people and team, not the other way around Key traits must
exist among the people on an agile team and the team itself:
Competence: In an agile development context, “competence” encompasses innate talent, specific
software –related skills. Skill and knowledge of process can and should be taught to all people who
serve as agile team members.
Common focus: The members of the agile team may perform different tasks and bring different skills
to the project, all should be focused on one goal—to deliver a working software increment to the
customer within the time promised.
Collaboration: To accomplish the tasks, team members must collaborate — with one another and all
other stakeholders.
Decision-making ability: The team should be given autonomy—decision making authority for both
technical and project issues.
Fuzzy problem-solving ability: Software managers must recognize that the agile team will continually
have to deal with ambiguity and will continually be buffeted by change. In some cases, the team
must accept the fact that the problem they are solving today may not be the problem that needs to
be solved tomorrow. The lessons learned from any problem-solving activity be of benefit to the team
later in the project.
Mutual trust and respect: The agile team must exhibits the trust and respect that are necessary to make
them strong.
Self-organization: Self-organization implies three things: (1) the agile team organizes itself for the work
to be done, (2) the team organizes the process to best accommodate its local environment, (3) the team
organizes the work schedule to best achieve delivery of the software increment.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 EXTREME PROGRAMMING (XP)

The most widely used agile process, originally proposed by Kent Beck. XP is lightweight, efficient,
low-risk, flexible way to develop the software. Used by small and medium sized teams that work under
rapidly changing requirements. More recently, a variant of XP, called Industrial XP (IXP) has been
proposed.

1.XP Values
2.XP Process
3.Industrial XP(IXP)
4.The XP Debate

1.Xp Values: A set of five values that establish a foundation for all work performed as part of XP.
 Communication:An effective communication between software engineers and
Other stakeholders should establish. 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 documentation as a
communication medium.
 Simplicity: XP restricts developers to design only for immediate needs, rather than consider future
needs ie: to create a simple design that can be easily implemented in code.
 Feedback: Feedback is derived from three sources the implemented software itself, the
customer, and other software team members.
 Courage: An agile XP team must have the discipline (courage) to design for today, recognizing
that future requirements may change dramatically, thereby demanding substantial rework of the
design and implemented code.
 Respect: The agile team inculcates respect among it members, between other stakeholders and
team members, and indirectly, for the software itself.

2. XP Process:

Extreme Programming uses an object-oriented approach as its preferred development paradigm

and encompasses a set of rules and practices that occur within the context of four framework
activities: planning, design, coding, and testing.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

XP Planning:
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a cost.
 Stories are grouped to for a deliverable increment.
 A commitment is made on delivery date.
 After the first increment “project velocity” is used to help define subsequent delivery dates for
other increments.

XP Design:
 Follows the KIS(Keep it simple) principle.
 Encourage the use of CRC cards (class responsibility collaborator).
 For difficult design problems, suggests the creation of “spike solutions”—a design prototype
Note:
Spike solution: A spike solution is a very simple program to explore potential solutions . Difficult solutions
should be modelled using prototype.
XP Coding:
 Recommends the construction of a unit test for a store before coding commences.
 Encourages “pair programming”.
 Pair Programming: Two people work together at one computer workstation to create code for a
story. This provides a mechanism for realtime problem solving (two heads are often better than one)
and real-time quality assurance (the code is reviewed as it is created).
 Encourages “refactoring”—an iterative refinement of the internal program design.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Refactoring : Improves the internal structure of the code but external behaviour not affected.

XP Testing:
 All unit tests are executed daily.
 “Acceptance tests” are defined by the customer and executed to assess customer visible functionality.

3. Industrial XP(IXP):
IXP differs most from the original XP in its greater inclusion of management, its expanded role for
customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed
to help ensure that an XP project works successfully for significant projects within a large
organization.

Readiness assessment:
Prior to the initiation of an IXP project, the organization should conduct a readiness assessment. The
assessment ascertains whether
(1) an appropriate development environment exists to support IXP
(2) the team will be populated by the proper set of stakeholders
(3) the organization has a distinct quality program and supports continuous improvement
(4) the organizational culture will support the new values of an agile team
Retrospectives:
An IXP team conducts a specialized technical review after a software increment is delivered called a
retrospective.
Continuous learning:
The members of the XP team are encouraged (and possibly, incented) to learn new methods and techniques
that can lead to a higher quality product.
Project community:
When XP is to be applied for a significant project in a large organization, the concept of the “team” should
morph into that of a community.
Project chartering:
Chartering examines the context of the project to determine how it complements, extends, or replaces
existing systems or processes.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Test-driven management:
Test-driven management establishes a series of measurable “destinations” and then defines mechanisms for
determining whether or not these destinations have been reached(ie:assessing the state of the project and the
progress that has been made to date).

4. The XP Debate :
Among the issues that continue to trouble some critics of XP are:
a) Requirements volatility: The changes to requirements are requested informally by the customer. As
a consequence, the scope of the project can change and earlier work may have to be modified
to accommodate current needs.
b) Conflicting customer need : In XP, the team itself is tasked with assimilating the needs of different
customers, a job that may be beyond their scope of authority.
c) Requirements are expressed informally : Proponents counter that the changing nature of
requirements makes such models and specification obsolete almost as soon as they are
developed.
d) Lack of formal design : XP proponents suggest that the incremental nature of the XP process
limits complexity (simplicity is a core value) and therefore reduces the need for extensive design.

 OTHER AGILE PROCESS MODELS

Many other agile process models have been proposed and are in use across the industry. Among the most
common are:

• 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)

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

ADAPTIVE SOFTWARE DEVELOPMENT (ASD) :

Adaptive Software Development (ASD) has been proposed by Jim Highsmith [Hig00] as a technique for
building complex software and systems. ASD focus on human collaboration and team self- organization.

ASD — distinguishing features

 Mission-driven planning
 Component-based focus
 Uses “time-boxing”
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process

ASD “life cycle” incorporates three phase:

 Speculation
 Collaboration
 Learning

adapt ive cycle planning Requirement s gat hering

uses mission st at ement J AD
project const raints mini-specs
basic requirement s
t ime-boxed release plan

Release
software increment
adjustments for subsequent cycles
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems

Speculation :
Here the project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning
uses project initiation information—the customer’s mission statement, project constraints (e.g.,

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

delivery dates or user descriptions), and basic requirements—to define the set of release cycles
(software increments) that will be required for the project.

Collaboration:
It encompasses communication and teamwork, but it also emphasizes individualism, because
individual creativity plays an important role in collaborative thinking. It is, a matter of trust.
People working together must trust one another to (1) criticize without animosity, (2) assist without
resentment, (3) work as hard as or harder than they do, (4) have the skill set to contribute to the work
at hand, and (5) communicate problems or concerns in a way that leads to effective action.
Learning: It will help team members to improve their level of real understanding. ASD teams
learn in three ways: focus groups, technical reviews and project postmortems.

SCRUM:
• Originally proposed by Schwaber and Beedle
• Scrum—distinguishing features
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is constructed
• Work occurs in “sprints” and is derived from a “backlog” of existing requirements
• Meetings are very short and sometimes conducted without chairs
• “demos” are delivered to the customer with the time-box allocated

Scrum (the name is derived from an activity that occur during a rugby match13) is a software
development that was proposed by Jeff Sutherland and his development team in the early 1990s.
Scrum principles are consistent with the agile manifesto and are used to guide development
activities within a process that incorporates the following framework activities: requirements,
analysis, design, evolution, and delivery.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Roles:
The Scrum Team consists of three roles, namely a Scrum Master, a Product Owner, and the Team.
1. Product Owner:
 The Product Owner is the sole person responsible for managing the Product Backlog.
Product Backlog management includes-
 Expressing Product Backlog items clearly.
 Ordering the Product Backlog items to best achieve goals and missions.
 Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team
will work on further.
 Ensuring that the Team understands items in the Product Backlog to the level needed.

2. Scrum Master: Is the keeper of the scrum process. He/she is responsible for-
 making the process run smoothly
 removing obstacles that impact productivity
 organizing and facilitating the critical meetings

3. Team: The Team is self-organizing and cross-functional.

 That means the team comprises of analysts, designers, developers, testers, etc. as appropriate and
as relevant to the project. Size of the team should be 5-9 members.
Scrum Process Framework can be viewed by means of a sequence of events and the corresponding
artifacts. The Scrum events are time-boxed events.
The vital events of scrum are-
 The Sprint
 Sprint Planning

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 Daily Scrum Meetings

 The Sprint Review
 The Sprint Retrospective

 In Sprint planning, the work to be performed in the Sprint is planned collaboratively by the Scrum
Team.
 The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to synchronize the
activities and create a plan for that day.
 A Sprint Review is held at the end of the Sprint to inspect the Increment and make changes to the
Product Backlog, if needed.
 The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this
meeting, the Scrum Team is to inspect itself and create a plan for improvements to be enacted during
the subsequent Sprint.
Terminologies:
Sprint: Within each framework activity, work tasks occur within a process pattern called a sprint.
Backlog: a prioritized list of project requirements or features that provide business value for the customer.
Product Backlog: The Product Backlog is an ordered list of features that are needed as part of the end product
and it is the single source of requirements for any changes to be made to the product
Sprint Backlog: The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal
Demos: deliver the software increment to the customer so that functionality that has been implemented can
be demonstrated and evaluated by the customer.

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)/ATERN:

 The Dynamic Systems Development Method (DSDM) is an agile software development approach
that “provides a framework for building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project environment”
 . The DSDM philosophy is borrowed from a modified version of the Pareto principle—80 percent of
an application can be delivered in 20 percent of the time it would take to deliver the complete (100
percent) application.
Guiding principles of DSDM:
 Active user involvement is imperative. DSDM teams must be empowered to make decisions.
 The focus is on frequent delivery of products.
 Fitness for business purpose is the essential criterion for acceptance of deliverables.
 Iterative and incremental development is necessary to converge on an accurate business solution.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 All changes during development are reversible.

 Requirements are baselined at a high level

1. Feasibility foundations:
Feasibility study:
 In this phase the problem is defined and the technical feasibility of the desired application is verified.
Apart from these routine tasks, it is also checked whether the application is suitable for Rapid
Application Development (RAD) approach or not. Only if the RAD is found as a justified approach
for the desired system, the development continues.
Business study:
 In this phase the overall business study of the desired system is done. The business requirements are
specified at a high level and the information requirements out of the system are identified. Once this is
done, the basic architectural framework of the desired system is prepared.
2. Exploration:
Functional Model Iteration:
The main focus in this phase is on building the prototype iteratively and getting it reviewed from the
users to bring out the requirements of the desired system. The prototype is improved through
demonstration to the user, taking the feedback and incorporating the changes. This cycle is repeated
generally twice or thrice until a part of functional model is agreed upon.
3. Engineering:
Design and build iteration:

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Revisits prototypes built during functional model iteration to ensure that each has been engineered in a
manner that will enable it to provide operational business value for end users. In some cases,
functional model iteration and design and build iteration occur concurrently

4. Implementation:

Implementation is the last and final development stage in this methodology. In this phase the users are
trained and the system is actually put into the operational environment. At the end of this phase, there
are four possibilities, as follows :
 Everything was delivered as per the user demand, so no further development required.
 A new functional area was discovered, so return to business study phase and repeat the whole process
 A less essential part of the project was missed out due to time constraint and so development returns to
the functional model iteration.
 Some non-functional requirement was not satisfied, so development returns to the design and build
iterations phase.

CRYSTAL
Jim Highsmith created the Crystal family of agile methods in order to achieve a software development
approach that puts a premium on “maneuverability” during what Cockburn characterizes as “a resource-
limited, cooperative game of invention and communication, with a primary goal of delivering useful,
working software and a secondary goal of setting up for the next game”.
• Proposed by Cockburn and Highsmith
• Crystal—distinguishing features
Actually a family of process models that allow “maneuverability” based on problem characteristics
Face-to-face communication is emphasized
Suggests the use of “reflection workshops” to review the work habits of the team

 Crystal is an agile methodology for software development. It places focus on people over processes, to
empower teams to find their own solutions for each project rather than being constricted with rigid
methodologies.
 Crystal recognizes that different teams will perform differently depending on team size, criticality and
priority of the project and encourages users to adapt the framework for their individual situation.
 Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow,
Crystal Orange and others.
These are categorized by color, according to the number of people in the project;
 Crystal Clear - Teams with less than 8 people
 Crystal Yellow - Teams with between 10 and 20 people

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 Crystal Orange - Teams with between 20-50 people

 Crystal Red - Teams with between 50-100 people

Key Principles of the Crystal Framework:

1.Frequent Delivery:
 You should deliver code regularly to your real users. Without this, you might be building a product
nobody needs.
2: Reflective Improvement
 Look back on what you've done, how you've done it and why. As a team, reflect and decide how to
improve it in the future.
3: Osmotic Communication
 Cockburn believed that co-location (having teams in the same physical space) is critical as it allows
information to flow between team members.
4: Personal Safety:
 Team members should feel safe to discuss ideas openly, without fear . There are no wrong answers or
bad suggestions in a Crystal team.
5: Focus on Work:
 Team members should know what to work on next and be able to do it. This requires clear
communication and documentation when required.
6: Access to Subject Matter Experts and Users:
 Team members should be able to get feedback from real users and experts when required.
7: Technical Tooling:
 Teams should have access to toolings like continuous deployment, automated testing and
configuration management. This means errors and mistakes can be caught quickly without human
intervention.

FEATURE DRIVEN DEVELOPMENT

Originally proposed by Peter Coad is a model for object oriented software engineering.
 FDD adopts a philosophy that

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

(1) emphasizes collaboration among people on an FDD team;

(2) manages problem and project complexity using feature-based decomposition followed by the integration
of software increments,
(3) communication of technical detail using verbal, graphical, and text-based means.
• FDD—distinguishing features
• Emphasis is on defining “features”
• a feature “is a client-valued function that can be implemented in two weeks or less.”
• Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
• A features list is created and “plan by feature” is conducted
• Examples of features for an e-commerce application might be:
Making a product sale is a feature.
Then the feature set would include:
Add the product to shopping cart
Display the technical-specifications of the product
Store the shipping-information for the customer

The FDD approach defines five “collaborating” framework activities (in FDD these are called “processes”) .
FDD provides greater emphasis on project management guidelines and techniques than many other agile
methods.
.
LEAN SOFTWARE DEVELOPMENT (LSD):

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 Lean Software Development (LSD) is an agile framework based on optimizing development time and
resources, eliminating waste, and ultimately delivering only what the product needs.
 A primary goal of software development teams is delivering valuable features and products as quickly
and effectively as possible.
 The lean principles that inspire the LSD process can be summarized as eliminate waste, build quality
in, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole.

1. Eliminate waste: (1) adding no extraneous features or functions, (2) assessing the cost and schedule
impact of any newly requested requirement, (3) removing any superfluous process steps, (4)
establishing mechanisms to improve the way team members find information, (5) ensuring the testing
finds as many errors as possible, (6) reducing the time required to request and get a decision that
affects the software or the process that is applied to create it, and (7) streamlining the manner in which
information is transmitted to all stakeholders involved in the process.
2. Build quality in:
3. Create knowledge
4. Defer commitment
5. Deliver fast
6. Respect people
7. Optimize the whole.

AGILE MODELING (AM):

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of
software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices
for modeling software that can be applied on a software development project in an effective and light-weight
manner. Agile models are more effective than traditional models because they are just barely good, they don’t
have to be perfect.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

AM suggests a wide array of “core” and “supplementary” modeling principles, those that make AM unique
are:-
Model with a purpose: A developer who uses AM should have a specific goal (e.g., to communicate
information to the customer or to help better understand some aspect of the software) in mind before creating
the model. Once the goal for the model is identified, the type of notation to be used and level of detail
required will be more obvious.
Use multiple models: AM suggests that to provide needed insight, each model should present a different
aspect of the system and only those models that provide value to their intended audience should be used.
Travel light: As software engineering work proceeds, keep only those models that will provide long-term
value and jettison the rest. Every work product that is kept must be maintained as changes occur .
Content is more important than representation: Modeling should impart information to its intended audience.
Know the models and the tools you use to create them: Understand the strengths and weaknesses of each
model and the tools that are used to create it.
Adapt locally: The modeling approach should be adapted to the needs of the agile team.

AGILE UNIFIED PROCESS (AUP)

The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative in the small” philosophy
for building computer-based systems.
By adopting the classic UP phased activities—inception, elaboration, construction, and transition—
AUP provides a serial overlay (i.e., a linear sequence of software engineering activities) that enables
a team to visualize the overall process flow for a software project.
Each AUP iteration addresses the following activities :
Modeling: UML representations of the business and problem domains are created. However, to stay
agile, these models should be “just barely good enough” to allow the team to proceed.
Implementation: Models are translated into source code.
Testing: Like XP, the team designs and executes a series of tests to uncover errors and ensure that the
source code meets its requirements.
Deployment: Like the generic process activity deployment in this context focuses on the delivery of
a software increment and the acquisition of feedback from end users.
Configuration and project management:The context of AUP, configuration management
addresses change management, risk management, and the control of any persistent work products that
are produced by the team. Project management tracks and controls the progress of the team and
coordinates team activities.
Environment management: Environment management coordinates a process infrastructure that
includes standards, tools, and other support technology available to the team.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 A TOOL SET FOR THE AGILE PROCESS

There are many different types of Agile tools out there. Some are free, some are paid. There are many
enterprise tools that support end-to-end flow of software development life cycle including
requirements management, test management, defect tracking.
Some proponents of the agile philosophy argue that automated software tools (e.g., design tools)
should be viewed as a minor supplement to the team’s activities, and not at all to the success of the
team.
Some of those tools are social, starting even at the hiring stage. Some tools are technological, helping
distributed teams simulate being physically present. Many tools are physical, allowing people to
manipulate them in workshops.”

Because acquiring the right people (hiring), team collaboration, stakeholder communication, and
indirect management are key elements in virtually all agile process models, Cockburn argues that
“tools” that address these issues are critical success factors for agility.
Collaborative and communication “tools” are generally low tech and incorporate any mechanism
(“physical proximity, whiteboards, poster sheets, index cards, and sticky notes”) that provides
information and coordination among agile developers.

 SOFTWARE ENGINEERING KNOWLEDGE


•Many software practitioners think of software engineering knowledge almost
exclusively as knowledge of specific technologies: Java, Perl, html, C , Linux etc
•You often hear people say that software development knowledge has a 3-year half- life: half of what
you need to know today will be inoperative within 3 years.
•In the domain of technology-related knowledge, that’s probably about right.
•But there is another kind of software development knowledge—a kind that I think
of as "software engineering principles"—that does not have a three-year half-life.
•These software engineering principles are likely to serve a professional programmer throughout his or
her career.

 CORE PRINCIPLES
Principles that Guide Process:
•Principle #1. Be agile.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

•Principle #2. Focus on quality at every step..

•Principle #3. Be ready to adapt.

•Principle #4. Build an effective team.

•Principle #5. Establish mechanisms for communication and coordination.

•Principle #6. Manage. change

•Principle #7. Assess risk.

•Principle #8. Create work products that provide value for others.

Principles that Guide Practice:

Software engineering practice has a single overriding goal—to deliver on-time, high quality,
operational software that contains functions and features that meet the needs of all stakeholders.
•Principle #1. Divide and conquer.

•Principle #2.Understand the use of abstraction.

•Principle #3. Strive for consistency.

•Principle #4. Focus on the transfer of information.

•Principle #5. Build software that exhibits effective modularity.

•Principle #6. Look for patterns.

•Principle #7. When possible, represent the problem and its solution from a number
of different perspectives.
•Principle #8. Remember that someone will maintain the software.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY

• Communication Principles -- 10
• Planning Principles -- 10
• Modeling Principles --10
a) Requirements Modeling Principles --5
b) Design Modeling Principles --5
• Construction Principles
a) Preparation Principles --5
b) Programming Principles --9
c) Validation Principles --3 Testing Principles --5
• Deployment Principles --5

 Communication Principles

•Principle #1. Listen. Try to focus on the speaker’s words, rather than
formulating your response to those words.
•Principle # 2. Prepare before you communicate. Spend the time to
understand the problem before you meet with others.
•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; (2) to mediate
any conflict that does occur, and (3) to ensure than other principles are followed.
•Principle #4. Face-to-face communication is best. But it usually works
better when some other representation of the relevant information is present.
•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. Collaboration and aggrement occur when the collective
knowledge of members of the team is combined
•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.
•Principle # 8. If something is unclear, draw a picture.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

•Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to
something, move on; (c) If a feature or function is unclear and cannot be clarified at the
moment, move on.
•Principle # 10. Negotiation is not a contest or a game. It works best when both parties
win.

 Planning Principles
•Principle #1. Understand the scope of the project. It’s impossible to use a roadmap if you
don’t know where you’re going. Scope provides the software team with a destination.
•Principle #2. Involve the customer in the planning activity. The customer defines priorities
and establishes project constraints.
•Principle #3. Recognize that planning is iterative. A project plan is never engraved in stone.
As work begins, it very likely that things will change.
•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.
•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.
•Principle #6. Be realistic. People don’t work 100 percent of every day.

•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.
•Principle #8. Define how you intend to ensure quality. The plan should identify how the
software team intends to ensure quality.
•Principle #9.Describe how you intend to accommodate change. Even the best planning can
be obviated by uncontrolled change.
• Principle #10.Track the plan frequently and make adjustments as required. Software
projects fall behind schedule one day at a time.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 Modeling Principles

•Principle #1. The primary goal of the software team is to build software,

not create models.

•Principle #2. Travel light—don’t create more models than you need.

•Principle #3. Strive to produce the simplest model that will describe the

problem or the software.

•Principle #4. Build models in a way that makes them amenable to

change.
•Principle #5. Be able to state an explicit purpose for each model that is
created
•Principle #6. Adapt the models you develop to the system at hand.
•Principle #7. Try to build useful models, but forget about building
perfect models.
•Principle#8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation is
secondary.
• Principle #9. If your instincts tell you a model isn’t right even though it
seems okay on paper, you probably have reason to be
concerned.
• Principle #10. Get feedback as soon as you can.

•In software engineering work, two classes of models can be created:

– Requirements models (also called analysis models) represent the customer requirements by
depicting the software in three different domains: the information domain, the functional domain, and
the behavioral domain.
– Design models represent characteristics of the software that help practitioners to construct it
effectively: the architecture, the user interface, and component-level detail.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

 Requirements Modeling Principles

• Principle #1. The information domain of a problem must be represented

and understood.
• Principle #2. The functions that the software performs must be defined.
• Principle #3.The behavior of the software (as a consequence of external
events) must be represented.
• Principle #4.The models that depict information, function, and behavior
Must be partitioned in a manner that uncovers detail in a
layered (or hierarchical) fashion.
•Principle #5.The analysis task should move from essential information
Toward implementation detail.

 Design Modeling Principles

•Principle #1. Design should be traceable to the requirements model.

•Principle #2. Always consider the architecture of the system to be built.

•Principle #3. Design of data is as important as design of processing
functions.
•Principle #4. Interfaces (both internal and external ) must be designed
with care.
•Principle #5.User interface design should be tuned to the needs of the
end-user. However,in every case, it should stress ease of use.

 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.
•Coding principles and concepts are closely aligned programming
style, programming languages, and programming methods.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

•Testing principles and concepts lead to the design of tests that systematically uncover different
classes of errors and to do so with a minimum amount of time and effort.

Preparation Principles:
Before you write one line of code, be sure you:
•Understand of 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.
•Create a set of unit tests that will be applied once the component you
code is completed.

Programming principles
As you begin writing code, be sure you:
•Constrain your algorithms by following structured programming [Boh00] practice.
•Consider the use of pair programming
•Select data structures that will meet the needs of the design.
•Understand the software architecture and create interfaces that are consistent with it.
•Keep conditional logic as simple as possible.
•Create nested loops in a way that makes them easily testable.
•Select meaningful variable names and follow other local coding standards.
•Write code that is self-documenting.
•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

•After you’ve completed your first coding pass, be sure you:

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

•Conduct a code walkthrough when appropriate.

•Perform unit tests and correct errors you’ve uncovered.
•Refactor the code.

Testing Principles

–Principle #1. All tests should be traceable to customer requirements.

–Principle #2. Tests should be planned long before testing begins.

–Principle #3. The Pareto principle applies to software testing.
–Principle #4. Testing should begin “in the small” and progress toward testing “in the
large.”
–Principle #5. Exhaustive testing is not possible.
 Deployment Principles
• Principle #1. Customer expectations for the software must be managed.

• Principle #2. A complete delivery package should be assembled and

tested.
• Principle #3. A support regime must be established before the software
is delivered.
• Principle #4. Appropriate instructional materials must be provided to
end-users.
• Principle #5. Buggy software should be fixed first, delivered later

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Topics:

Requirements Engineering
Establishing the groundwork
Eliciting Requirements
Use cases
Building the requirement model
Negotiating Requirement
Validating Requirement

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

REQUIREMENTS ENGINEERING

The broad spectrum of tasks and techniques that lead to an understanding of requirements 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 builds a bridge to design and construction. Requirements engineering provides
the appropriate mechanism for understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the
specification, and managing the requirements as they are transformed into an operational system. It
encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation, specification,
validation, and management.
a) Inception. In general, most projects begin when a business need is identified or a potential new market
or service is discovered. Stakeholders from the business community 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.

At project inception, you establish a basic understanding of the problem, the people who want a solution,
the nature of the solution that is desired, and the effectiveness of preliminary communication and
collaboration between the other stakeholders and the software team.

b)Elicitation. Ask the customer, 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 system or
product is to be used on a day-to-day basis. A number of problems that are encountered as elicitation
occurs.
• Problems of scope. The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely sure of what is needed, have a
poor understanding of the capabilities and limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify requirements that conflict with the needs of other

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

customers/users, or specify requirements that are ambiguous or un testable.

• Problems of volatility. The requirements change over time. To help overcome these problems, you
must approach requirements gathering in an organized manner.

c) Elaboration. The information obtained from the customer during inception and elicitation is expanded
and refined during elaboration. This task focuses on developing

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

a refined requirements model that identifies various aspects of software function, behavior, and
information.

Elaboration is driven by the creation and refinement of user scenarios that describe how the end user (and
other actors) will interact with the system. Each user scenario is parsed to extract analysis classes—
business domain entities that are visible to the end user. The attributes of each analysis class are defined,
and the services that are required by each class are identified. The relationships and collaboration between
classes are identified, and a variety of supplementary diagrams are produced.

d)Negotiation. It usual for customers, to 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 conflicts
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.

e) Specification. Specification means different things to different people. A specification can be a written
document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a
prototype, or any combination of these. Some suggest that a “standard template” should be developed and
used for a specifcation, arguing that this leads to requirements that are presented in a consistent and
therefore more understandable manner. However, it is sometimes necessary to remain flexible when a
specification is to be developed. For large systems, a written document, combining natural language
descriptions and graphical models may be the best approach.

ESTABLISHING THE GROUNDWORK

In an ideal setting, stakeholders and software engineers work together on the same team. In such cases,
requirements engineering is simply a matter of conducting meaningful conversations with colleagues who
are well-known members of the team.

We discuss the steps required to establish the groundwork 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 is “anyone who benefits in a direct or indirect

way from the system which is being developed.” The usual stakeholders are: business

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

operations managers, product managers, marketing people, internal and external

customers, end users,

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

consultants, product engineers, software engineers, support and maintenance engineers. 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. Each
of these constituencies will contribute information to the requirements engineering
process. As information from multiple viewpoints is collected, emerging requirements
may be inconsistent or may conflict with one another. You should categorize all
stakeholder information in a way that will allow decision makers to choose an
internally consistent set of requirements for the system.

Working toward Collaboration: If five stakeholders are involved in a software

project, you may have five different opinions about the proper set of requirements.
Customers must collaborate among themselves and with software engineering
practitioners if a successful system is to result. The job of a requirements engineer is
to identify areas of commonality and areas of conflict or inconsistency. Collaboration
does not necessarily mean that requirements are defined by committee. In many cases,
stakeholders collaborate by providing their view of requirements, but a strong “project
champion” may make the final decision about which requirements make the cut.

Asking the First Questions: Questions asked at the inception of the project should be
“context free. The first set of context-free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. 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. In
addition, the questions identify the measurable benefit of a successful implementation and possible
alternatives to custom software development.

The next set of questions enables you to gain a better understanding of the problem 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?

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

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”?

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

• 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 will help to “break the ice” and initiate the communication that is essential to successful
elicitation.

ELICITING REQUIREMENTS

Requirements elicitation combines elements of problem solving, elaboration, negotiation, and specification.
Collaborative Requirements Gathering: Many different approaches to collaborative
requirements gathering have been proposed.
• 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” controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts etc) is used.

The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and
specify a preliminary set of solution requirements in an atmosphere that is conducive to the
accomplishment of the goal.

While reviewing the product request in the days before the meeting, 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.

The mini-specs are presented to all stakeholders for discussion. Additions, deletions, and further
elaboration are made. In some cases, the development of mini-specs will uncover new objects, services,
constraints, or performance requirements that will be added to the original lists. During all discussions, the
team may raise an issue that cannot be resolved during the meeting. An issues list is maintained so that
these ideas will be acted on later.

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 “concentrates 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 product or system during meetings
with the customer. If these requirements are present, the customer is satisfied.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

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 expectations 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.

Usage Scenarios: As requirements are gathered, an overall vision of system functions

and features begins to materialize. However, it is difficult to move into more technical
software engineering 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
constructed.

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 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.

Each of these work products is reviewed by all people who have participated in requirements elicitation.

DEVELOPING USE CASES

In essence, a use case tells a stylized story about how an end user 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.

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

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

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

the function and behavior that is to be described. It is important to note that an actor and an end user are
not necessarily the same thing. It is possible to identify primary actors during the first iteration and
secondary actors as more is learned about the system.
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. Jacobson suggests 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 THE REQUIREMENTS MODEL

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

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 understand

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

more about what they really require. For that reason, the analysis model is a snapshot of requirements at any
given time.

Elements of the Requirements Model: There are many different ways to look at the
requirements for a computer-based system. Different modes of representation force
you to consider requirements from different viewpoints—an approach that has a
higher probability of uncovering omissions, inconsistencies, and ambiguity.

Scenario-based elements. The system is described from the user’s point of view using a scenario-based
approach. For example, basic use cases and their corresponding use-case diagrams evolve into more
elaborate template-based use cases. Scenario-based elements of the requirements model are often the first
part of the model that is developed. Three levels of elaboration are shown, culminating in a scenario-based
representation.

Class-based elements. Each usage scenario implies a set of objects that are manipulated as an actor
interacts with the system. These objects are categorized into classes—a collection of things that have
similar attributes and common behaviors. Example shown in figure 5.4

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

Behavioral elements. The behavior of a computer-based system can have a profound effect on the design
that is chosen and the implementation approach that is applied. Therefore, the requirements model must
provide modeling elements that depict behavior.
The state diagram is one method for representing the behavior of a system by depicting its states and the
events that cause the system to change state. A state is any externally observable mode of behavior. In
addition, the state diagram indicates actions taken as a consequence of a particular event.

Flow-oriented elements. Information is transformed as it flows through a computer-based system. The

system accepts input in a variety of forms, applies functions to transform it, and produces output in a
variety of forms. Input may be a control signal transmitted by a transducer, a series of numbers typed by a
human operator, a packet of information transmitted on a network link, or a voluminous data file retrieved
from secondary storage. The transform(s) may comprise a single logical comparison, a complex numerical
algorithm, or a rule-inference approach of an expert system.

Analysis Patterns: Anyone who has done requirements engineering on more than a
few software projects begins to notice that certain problems reoccur across all projects
within a specific application domain. These analysis patterns suggest solutions (e.g.,

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

a class, a function,

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

a behavior) within the application domain that can be reused when modeling many applications. Analysis
patterns are integrated into the analysis model by reference to the pattern name. They are also stored in a
repository so that requirements engineers can use search facilities to find and apply them. Information
about an analysis pattern (and other types of patterns) is presented in a standard template.

NEGOTIATING REQUIREMENTS

In an ideal requirements engineering context, the inception, elicitation, and elaboration tasks determine
customer requirements in sufficient detail to proceed to subsequent software engineering activities. You
may have to enter into a negotiation with one or more stakeholders. In most cases, stakeholders are asked
to balance functionality, performance, and other product or system characteristics against cost and time-
to-market. The intent of this negotiation is to develop a project plan that meets stakeholder needs while at
the same time reflecting the real- world constraints (e.g., time, people, budget) that have been placed on
the software team.
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 win by working to realistic and achievable
budgets and deadlines.

Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration.
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.

VALIDATING REQUIREMENTS

As each element of the requirements model is created, it is examined for inconsistency, omissions, and
ambiguity. The requirements represented by the model are prioritized by the stakeholders and grouped
within requirements packages that will be implemented as software increments. 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 inappropriate 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 noted for each requirement?

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

• Do any requirements conflict with other requirements?

Downloaded by Chetan M ([email protected])

 lOMoARcPSD|44045213

• 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

Downloaded by Chetan M ([email protected])