Overview
● The notion of best practices is debatable: who decides what is "best" and on what basis?
§ One approach is to convene a body of industry experts or
researchers to analyze projects from many different organizations
●
These experts look for
practices whose effective performance is associated with successful projects
and which are performed poorly or not at all on failed projects.
●
The experts reach consensus
on the activities that consistently yield superior results.
●
Such activities are called best
practices.
§ They represent highly effective ways for software professionals
to increase the chance of success on certain kinds of projects and in certain
situations.
Requirements Engineering Good Practices
●
Table 3.1 lists nearly 50
practices, grouped into seven categories, that can help most development teams
do a better job on their requirements activities.
●
Several of the practices
contribute to more than one category, but each practice appears only once in
the table.
●
These practices aren't
suitable for every situation, so use good judgment, common sense, and
experience instead of ritualistically following a script.
1-
Knowledge
·
Because the requirements
process is essential, all project stakeholders should understand the concepts
and practices of requirements engineering.
·
Training can increase the
proficiency and comfort level of those who serve as analysts, but it can't
compensate for missing interpersonal skills or a lack of interest.
·
Similarly, developers
should receive grounding in the concepts and terminology of the application
domain.
●
Good practices in
knowledge include:
●
Train requirements
analysts.
§ All team members of RE process should receive basic training in
requirements engineering for several days. Skills include patient, well
organized, interpersonal and communication, understanding of the application
domain.
●
Educate user
representatives and managers about software requirements.
§ Users should receive one or two days of education about
requirements engineering. The training will help understanding the value of
emphasizing requirements, the activities and deliverables involved, and the
risks of neglecting requirements processes.
●
Train developers in
application domain concepts.
§ To help them achieve a basic understanding of the application
domain. This can reduce confusion, miscommunication, and rework down the road.
●
Create a project
glossary.
§ Include synonyms, terms that can have multiple meanings, and
terms that have both domain-specific and everyday meanings. This will reduce
misunderstandings.
2-Requirements Elicitation
●
As discussed in chapter 1,
levels of requirements are business, user, and functional.
●
These come from different
sources at different times during the project, have different audiences and
purposes, and need to be documented in different ways.
●
The business
requirements expressed in the project scope must not exclude any essential user
requirements, and you should be able to trace all functional requirements
back to specific user requirements.
●
You also need to elicit nonfunctional
requirements, such as quality and performance expectations, from
appropriate sources. You can find additional information about these topics in
the following chapters .
Good practices for eliciting requirements
include:
●
Define a requirements
development process.
●
This will provide guidance
and help analysts do a consistently good job. It also make it easier to plan
each project's requirements development tasks, schedule, and required
resources.
●
Write a vision and scope
document (business requirements).
●
The vision statement gives
all stakeholders a common understanding of the product's objectives. The scope
defines the boundary between what's in and what's out for a specific release.
Together, the vision and scope provide a reference against which to evaluate
proposed requirements.
●
Identify user classes
(groups) and their characteristics.
●
To avoid overlooking the
needs of any user community. Describe aspects of their job tasks, attitudes,
location, or personal characteristics that might influence product design.
●
Select a product
champion for each user class.
●
The product champion
presents the needs of the user class and makes decisions on its behalf. Product
champions must have the authority to make decisions at the user-requirements
level.
●
Establish focus groups
of typical users.
●
Convene groups of
representative users of your previous product releases or of similar products.
Collect their input on both functionality and quality characteristics for the
product under development. Unlike product champions, focus groups generally do
not have decision-making authority.
●
Work with user
representatives to identify use cases.
●
Explore with your user
representatives the tasks they need to accomplish with the software—their use
cases. Discuss the interactions between the users and the system that will
allow them to complete each such task.
●
Identify system events
and responses.
●
List the external events
that the system can experience and its expected response to each event. Events
include signals or data received from external hardware devices and temporal
events that trigger a response, such as an external data feed that your system
generates at the same time every night. Business events trigger use cases in
business applications.
●
Hold facilitated
elicitation workshops.
●
Facilitated
requirements-elicitation workshops that permit collaboration between analysts
and customers are a powerful way to explore user needs and to draft
requirements documents . Specific examples of such workshops include Joint
Requirements Planning (JRP) sessions and Joint Application Development (JAD)
sessions.
●
Observe users performing
their jobs.
●
Simple workflow diagrams—data
flow diagrams work well—can depict when the user has what data and how that
data is used. Documenting the business process flow will help you identify
requirements for a system that's intended to support that process.
No comments:
Post a Comment