Assignment 6
Question 7.1 How do you fit SRS documentation into an agile framework?
Answer 7.1: SRS documentation can fit into an agile framework is all necessary parties are
involved. This includes the necessary stak
...
Assignment 6
Question 7.1 How do you fit SRS documentation into an agile framework?
Answer 7.1: SRS documentation can fit into an agile framework is all necessary parties are
involved. This includes the necessary stakeholders, requirements engineers, and design engineers
weighing in on the wording of requirements. If there are no requirements defined at the beginning of
a project or program, SRS documentation can be used to show the evolution of the requirements
from the inception of the project through the cycles it goes through to mature. It can be configuration
controlled (though that would take more time), or the history of requirements changes can be tracked
in a requirements management system such as DOORS. Provided stakeholders are easily available
to provide feedback, the SRS documentation can continuously evolve and keep up with the timeline
of the agile framework.
Question 7.2: Is it possible to use agile methodologies when the customer is not on site? If so, how?
Answer 7.2:
Agile favors (but does not require) face-to-face communications, with team members committed to
the project and able to maintain a constant pace indefinitely. Daily stand-up meetings during the
sprint, planning meetings and product demos at the beginning and end of the sprint, and other
components of the Agile methodology work best when these assumptions are true.
This works great when you can have it. Small businesses with multiple contracts of varying sizes
and durations may need to be more flexible, able to change the team as practical demands dictate,
and split peoples’ time across multiple projects concurrently. This often gets in the way of the higher
degree of team synchronization which Agile favors.
Hybrid Methodology
Within the confines of what we agree upon with our customers, we often utilize a combination of
iterative and more traditional methodologies to get our work done. For instance, we may use a type
of sprint internally within the development team as a way of organizing the work. We utilize a backlog
and frequent communications (like stand-up meetings) to keep the team moving forward. We
conduct sprint reviews with the customer, but may need to limit (or completely curtail) changes.
Question 7.3 Why are agile methodologies generally not suitable for hardware-based projects as
opposed to software projects?
Answer 7.3:
Similarities between Hardware and Software Development
Software products, hardware products, and combinations of the two in the same product share these
characteristics:
• They have behavior: Users interact with the products in various ways, products interact with other
products, and products produce outputs given inputs
• They have functional (user-facing) and non-functional (non-user-facing) requirements
• They are complex: Any representation of product specifications invariably leads to a tree structure, as
major features are decomposed into finer-grained features
Differences between Hardware and Software Development
Software and hardware products differ in these ways:
• Software is more malleable (easier to change) than hardware. The cost of change is much higher for
hardware than for software.
• Software products evolve through multiple releases by a process of accretion and refactoring (adding
new features and re-writing existing logic to support the new features). Hardware products consist largely
of physical components that cannot be “refactored” after manufacturing, and cannot “accrete” newcapabilities that require hardware changes. Designs for new hardware products are often based upon
earlier-generation products of similar type, but commonly rely on next-generation components that were
not present in earlier generations of the product.
• New versions of software and hardware products are both constrained by the design and capabilities of
previous versions, but the accretional nature of software development allows for more latitude in deciding
what to develop than is the case for hardware. Upgraded versions of hardware products typically have less
scope for major qualitative changes, and focus more on quantitative improvements of existing
capabilities.
• Hardware designs are constrained by the need to incorporate standard parts.
• Specialized hardware components can have much longer lead times for acquisition than is true for
software.
• The design for a hardware product is driven in large part by architectural decisions. As the cost of
change is high, more of the architectural work must be done up front compared to software products. 14
• Testing software commonly requires developing thousands of test cases, with perhaps a few to a few
tens of new test cases being developed per month over the life of the product. Hardware testing involves
far fewer tests, but more specialized and expensive equipment.
• Software testing is commonly done by, or defined by, specialized Quality Assurance (QA) engineers,
while hardware testing is commonly done by the engineers who are creating the product.
• Hardware must be designed and tested to work over a range of time (aging) and environmental
conditions, which is not the case for software.
• Hardware development incorporates four parallel, synchronized projects: 1) The detailed design of the
manufacturable product; 2) the manufacturing process and tooling; 3) the test and inspection process and
equipment; and 4) the supply chain for purchased parts. In software development, the detailed design is
the product, and production deployment consists of moving the product into a context where it can be
used.
• The cost of development for software products is relatively flat over time (aside from the usual hiring
and attrition). However, the cost of hardware development rises rapidly towards the end of the
development cycle for hardware products.
• Due to many of the above factors, it is possible to make major changes in direction for a planned
software-product upgrade in mid-development, without massive disruption and waste. Attempts to make
such changes in hardware development come at a much higher cost, in terms of sunk costs wasted, and
shipping schedules postponed. As a result, major changes must either be deferred to a future product
upgrade, or are done when an assessment is made that the impact is justified by the magnitude of the
benefits.
Question 7.4: 7.4 Why can it be difficult for agile methodologies to cover nonfunctional
requirements?
Answer 7.4::
Basically, non-functional requirements relate to qualities of the system that cut across user facing
features, such as security, reliability, and performance. Non-functional is probably a bad name
because it sounds like these requirements are intangible, simply properties of a static system.
However, these requirements do affect the function of the system and it is possible to design tests
that these qualities are present.
The difference from functional requirements is that these qualities must be present throughout the
system rather than delivered in one-shot like a user facing feature. Alternative terms for nonfunctional requirements are "constraints", "quality attributes", "quality goals" and "quality of service
requirements" but let's stick to calling them "non-functional requirement" (NFR) for now.
NFR’s are not specified by the business or end customer instead they are considered to be include
in the build in agile process but that is not the case. NFR’s are the biggest reasons for long backlogs.There are no clearly defined User stories for NFR;s and no owners for these stories apart from the
development team, hence it is mostly difficult to cover NFR’s.
7.6 For the pet store POS system, generate a user story for customer purchases.
Answer 7.6:
Title: Customer gives back product
[Show More]
