PMP Primer Masterclass Online Training
Shares
Shares

requirements-300x253Project Requirements Excellence – Part 3

Defining business data from the logical Perspective, presents three major concerns:

  • The entities
  • Entity attributes
  • Entity relationships

I will now define these entities in more detail.

The business may want to store a lot of valuable information, but when it comes to the question of storage and where the business would pay to keep track of it, you need to push your business stakeholders to think about their data requirements carefully, remembering that data stored must be maintained, tracked, tracked, validated, and retrieved.

What is most important here is the use of configuration management. This business-critical service is often a continually resourced central function that provides configuration management services across the whole of your organization – particularly for use by your projects.

It is therefore important that you discuss with stakeholders what the financial impact of the data requirements will have.

Requirement Entities

Entities are the biggest pieces of business data, and they represent major information elements.

An entity is a uniquely Identifiable person, Thing, or concept that the business cares about and want to store information for.

Entity data is stored within tables, and as a requirement, an entity is a named noun, Described by a textual definition.

Requirement Attributes

Named with nouns or noun phrases, attributes capture the many details known about an entity. They are stored as columns with a table and the pieces of information typically included on screens, web pages, and reports.

The most important, and of attributes collect information about the business day to entities.To make it obvious which attributes describe data fields for which entity, business analysts, commonly prefix attributes with that entity name in capitals.

Some examples are EMPLOYEE.first-name, EMPOYEE.last-name, and BUSINESS-UNIT.name

Beyond the business information, you must also be concerned with attributes of the attributes. These characteristics describe the Meta data about an entity and its attributes.

Meta data is essentially data about the data.

Attributes from a business perspective store business information about the entities, but attributes from a requirements perspective store information about the physical characteristics of each data field within the table.

Clearly identifying what these characteristics are is critical for the data requirements and for ensuring the appropriate behavior of the solution. These sub attributes include uniqueness and cardinality. Here are the definitions:

Requirement Uniqueness

The first question to be answered about an attribute is whether it is unique for every occurrence. For example, if the attribute PERSON.first-name is specified as a unique attributes, one and only one occurrence of that entity can have that value.

If your personal information is captured within the solution, then no other person occurring in the database can have the same first name as you.

Requirement Cardinality

The second and third questions deal with the attributes cardinality. This is whether an attribute may, Or must have zero, one, or multiple values.

First, you must determine whether the attribute is a mandatory field: Must data for this attribute be captured, or can the attribute value be left blank? If the attribute is optional, no data needs to be captured and blanks are okay.

If the attribute is mandatory, something must be entered or an error will occur. In the first name example, if first name is mandatory, you must enter a name as some sort. You cannot enter anyone into the database and not know and record what their first name is.

The third question is about repetition. If an attribute has orders allowed repetition, then the business expects to collect multiple valid values For that attribute.

You must consider whether the business is describing a single value field – Where the entity has one and only one of these things – Or whether the entity the attribute describes may have, , It may be a collection of these attributes.

Repetitive attributes are frequently used to allow business stakeholders to collect different types of the same attributes or the same attributes across different points in time.

An example of a repetitive attribute is PERSON.address

Just think about how many addresses a person may have now: a home address, a work address, a shipping address they prefer for deliveries, a Billing address, and maybe even a vacation address. As an individual goes through their life, they may rack up several of each of these as they move from place to place.

Jump On Over To Part 4 HERE!