models are important as they address general problems and propose widely
accepted solutions. They can be used as a basis for the construction of
particular models. They save time and effort 29 . A general requirements
reference model was proposed by Gunter et al. in 2000 22 . Ramesh and Jarke
proposed a requirements specific reference traceability model which has three
basic elements in 2001 32 :
Stakeholder : People wh o have an interest on requirements.
Source : The origins of a requirement and the artifacts.
Object : Object being traced.
Mohan and Ramesh formed a
knowledge management system 26 in 2002 based on the reference traceability
model described in 32.
Business Rules Group
declared a Business Rules Manifest o in 2003 describing some major aspects of
business rules and related processes 41.
Cleland – Huang, Chang and
Christensen proposed a new method of traceability called ” Event – Based Tra
ceability ” based upon event – notification in 2003. This method is applicable
in globally distributed development environments. Traceable artifacts are
linked through an event service 8. Notification method is used in current
requirements management and traceability tools. This method is very helpful to
developers responsible from different kinds of requirements artifacts as they
can learn the changed artifacts with out any guidance from the developers who
is the source of the change. However, software requirements should be
effectively separated in different kinds to get advantage of such a scheme. Pinheiro
divides traceability into two groups 29 :
Inter – requirements traceability refers to the
relationships between requirements. Inter – requirements traceability is
important for requirements change and evaluation. It is used, f or example,
when extracting all requirements derived from a specific requirement or its
chain for refinement.
Extra – requirements traceability refers to the
relationships between requirements and other artifacts.
Inter – requirements
traceability is similar to vertical traceability. Its granularity level is
lower than extra – requirements traceability. Today research concerning this
kind of traceability is gaining attention.
III. research methodology
In previous sections we
can see that
Development teams do not
care about business rules at the beginning of the software project in general.
H ence , at the end of a software project , a problem can be found even at
acceptance tests. While collaborating with the customer at the beginning of the
requirement analysis; if enough effort does no t exist or business rules are no
t seen valuable enough for formally indicating; in later phases, business rules
come as change requests and rework in spi te of customer requirements.
Business rules are
identified in the normal course of requirements gathering and analysis. While
you are use case and domain modeling, you will often identify business rules.
Use – cases and business
rules are different in nature. Use – cases have several advantages , but it is
not possible to express all the business by using pure use – case approach.
Most of the sentences that customers say are business rules, not steps in a use
case . B usiness rules look at the system from viewpoint of business, the core
of the system . Therefore , it is crucial to give enough attention to collect
business rules in a formal way. It is a common mistake to put business r ules
as notes in to use – cases . By this way software design and implementation
becomes complex and highly coupled. That i s why business – rule e ngine
approach gains attention and many of them are evolving. Data defi nitions
should be mentioned as software requirements . They are at the core, they are
metadata. They should be traced and synchronized with other software
requirements by a requirem ent tool, not as excel files, etc. Use – cases,
business rules and data definitions are related to each other and they all
should be seen as p arts of a system that should work together to make the
system work properly. Business rules are open to change and t his
One of the approaches for
software req uirements is use – case approach . I t is widely accepted and used
by the industry . U se – case steps aims interaction between the end – user and
the system. A
use case describes
“who” can do “what” with the system in question 39 .
makes change requests and
business rules good friends. Therefore, it is a good idea to build a
traceability model with these software requirement types and make it business
3.1 STRUCTURE OF THE
There was a need to build a
general understanding of the software requirements at the beginning of the
project . As this need primarily focuses on functional requirements, three
types were decided to be used; use cases , business rules and data definitions .
For these types of software requirements, specific definitions were made with
the development team. Because, these definitio ns may and should be different
among projects according to the context s , restrictions and targets . Hence,
every project should think about and create their own templates and roadmap to
form the types and the definitions of the software requirements that is going
to be used in the project as described in Appendix
. Then, templates and naming
conventions were formed in order to provide right usage of these requiremen t
types and definitions ; moreover lead the development team .
Every software requirement
belongs to every development team member of the project to provide developer
independency. This issue is also important for CMMI processes
. Software requirements can
be modified or deleted by the development team . However, owner approach is
used . Software requirements have an owner who is the author of that
requirement. Whe n there is a need to modify that requirement, responsible of
the task or change request is that person. This prevents the potential chaos of
software requirements changes. But responsible person may change according to
the workload of the people and priori ties of other change requests and tasks.
A metadata repository was
decided to be used in order to keep the data definitions . R equirements
management tool is used as the metadata repository. E very developer can reach
the latest version of the data definitio ns easily . Metadata can be always updated
according to changing requirements in this common repository. It is not usable
and maintainable to keep the metadata as files . Because , there may be several
versions of the metadata if
a common repository is not used and this can easily cause software verification
and validation problems .
Several business rules which
the customer did not mention can be caught by thinking on data definitions.
Data definitions are valuable sources to understand the general structure of
the software . For instance , if a data definition is auto matically assigned
by the software , several business rules can arise in minds reg arding how that
data definition is managed by the software . This also shows that th ere is an
impact of data definition changes on business rules.
Business rules can be
implemented i n different layers of the software like database, data access
object (DAO) , service or client . It is important to make a clear distinction
between business ru les; hence it can be possible to give right decis ions
about what is going to be a ffected due to a change request. Every business
rule should give information a bout how it lives in the software . These
attributes are satisfied through different aspects of th e business rule
approach used in the project.
Use case approach is a
widely accepted approach for collecting and describing functional requirements.
This project also takes advantage of use case approach by modifying and doing
some extensions. As business requirements form a basis for user requirements
and business rules drive user requirements; there is an impact of business rule
changes on use cases.
Requirement management tools do not provide semantic linking in a
detailed manner . They are limited to so me refer