Information Technology Reference
In-Depth Information
5.1.3 Domain Requirements
Domain requirements include specialized domain terminology or reference to
domain concepts. Since these are specialized, software engineers often find it
difficult to understand how they are related to other system requirements. Domain
experts may leave information out of requirement simply because it is so obvious
to them. However, it may not be obvious to the developers of the system, and they
may, therefore, implement the requirement in the wrong way. There could be a
request for a user interface specification or a copyright constraint on a particular
software released. The developers in the first case must find out how to design the
specified user interface and in the second case the developers must design copy-
right information available to all the users, popping up when a user attempts to use
the software. These are two extra requirements that will be added according to the
operation performed by the software (Sommerville
2004
).
5.2 Requirement Elicitation
Requirements definition conversations often center on what to do, techniques to use,
or methods to follow. But requirement definition either succeeds or fails based on
how well people can work together. Success of the requirement elicitation process
depends on dealing with interpersonal, cultural and organizational aspects of
adopting these methods. A business analyst discovers the system requirements
through customers and experts in the problem domain. Requirements elicited from
the customers are expressed in use case scenarios. The task of a business analyst is to
combine the two sets of requirements into a business model. Requirement elicitation
is distinguished into two categories as traditional and modern methods. Traditional
methods involve interviewing customers, questionnaires, observation and studying
documents. However, the modern method involves prototyping, Joint Application
development (JAD), Rapid Application Development (RAD) (Maciaszek
2001
).
5.2.1 Communicating with the Client
First the developers and customers must develop a shared understanding of
problems and technical solutions. Then the team leaders and members who did not
talk to customer need to understand what was learned through proper team con-
versations. Finally, organizational functions-design, engineering, marketing, doc-
umentation, testing and customers must also understand the problem and agree to
the technical solution. Customer-centered techniques necessitate face-to-face
communication, continuous, synchronous team work in design meetings, shared
decision-making, and consensus (Holtzblatt and Beyer
1995
).
