Вы находитесь на странице: 1из 2

Charchit Piya

Fall 2016 8W II
Weekly Reading QAs Week 2

1 Describe the SWEBOK in relation to the waterfall methodology.


SWEBOK or Software Engineering Body of Knowledge provides guide for the entire
software development life cycle that is provided in form of Knowledge Areas.
SWEBOK principles are defined in 15 different knowledge areas. Likewise, Waterfall
methodology is very traditional method of Software Developmental Life Cycle
(SDLC). It includes systematic approach through each phases of SDLC. It prioritizes
on more documentation and completeness of each phases. Most of the procedures
as described in SWEBOK Knowledge Areas are followed thoroughly in the waterfall
methodology.

The key Knowledge Areas of SWEBOK defines Software Requirements, Design,


Construction, Testing, Maintenance, Configuration Management, Engineering
Management, Engineering Process, Engineering Models and Methods, Quality,
Professional Practices, Engineering Economics, Computing Foundations,
Mathematical Foundations and Engineering Foundations. It discusses the important
disciplines that are required. SWEBOK principles are very traditional and classic
approach for any software development, it requires the provided techniques and
documentation and for this reason it is very comparable with the waterfall
methodology. Waterfall methodology is also very descriptive and it requires to
follow all the traditional rules for software management.

2 Identify the parts of the Requirements Development & Management processes.

Software requirement engineering compromises of two distinctive parts that are


Requirements Development and Management Processes. Requirement Development
consists of Elicitation, Analysis, Specification and Validation. It includes the key
elements and processes that are required for determining, creating, and validating
the requirements.
Requirement management consists of Knowledge of Requirements and Project
management defining the baseline that represents an agreed upon snapshot of the
requirements. It helps in keeping project plans current with requirements as they
change. It also helps in defining the dependencies between requirements. It
includes tracing and tracking requirement status and their changes throughout the
project.

3 Describe the skills of a successful business/system analyst.

Some of the skills of a successful business/system analyst are Good listener,


Modeler, Creative, Negotiating Skills, Patient and thorough and organized. Business
analyst should be able to hear, understand and translate requirements. They should
also be able to create and present various solutions to the business requirements.
They should also be able to keep project within the scope and budget. They should
also be patient during the whole process and should be able to go through tiny
details of the project requirements and functions. They should be organized and do
a neat job in documenting and present the finding of the requirement analysis.

4 Discuss the key differences between user stories and use-cases.

A use case is a generalized description of a set of interactions between the system


and one or more actors, where an actor is either a user or another system. It can
be written in unstructured text. For example, customer can pay for the bike rental
with credit card online.
User stories is a tool to support iterative and incremental process used commonly in
Agile methodologies. Scope, completeness and longevity are some of the key
differences between user stories and use cases. User stories are kept smaller in
scope to place constraints on their size and they may be used in scheduling work.
User stories have smaller scope than use cases. Stories often correspond t use
case’s main success scenarios, and that the user story’s test correspond to the
extension of the user case. Use cases are often permanent artifacts that continue to
exist as long as project is under development but stories are not intended to live
more than the iteration that they are added to.

5. Explain the advantage to thinking about users’ goals rather than listing the
attributes of software to be built?

User goals tend to provide more understanding for a project or the product that is
being developed. It cannot be achieved with the attributes of the software to be
built. With using the user goal, at the end of the project, we can call the project as
success as it meets all the user goals, it might not be the case with using the
attributes of software to be build.