PMP Primer Masterclass Online Training
Shares
Shares

requirements-300x253Project Requirements Excellence Part 4

Requirement Relationships

The last major concern in data requirements is the data as relationship to other pieces of data in a database. Relationships are defined by using keys, or relationship identifies, that connect data tables together.

They are also attributes, but they are special attributes in that they provide unique identifiers for individual data elements, and denote relationships an entity has two other entities or attributes.

Data relationships also have cardinality defined.

You must define whether a relationship must exist, for example a salary data is captured, it must be related to an employee, or is optional, where a person may or may not have a dependent, and whether any relationship that exists is expected to be repetitive between of related entities.

A person may have a relationship to more than one dependent.

Requirement Process (use cases)

A process is something a person or thing does that get stuff done. It is the collection of individual steps, activities, or other process is that together transform data and achieve an end goal – For example “pay vendor invoice” or “find a local doctor”.

Process is and use cases (Written accounts of the sequence of steps performed by a user of an application to accomplish a complete business transaction), May be implemented as programs, modules, screens, all reports and can be Manual where people perform each individual step, or electronic where systems perform each step.

More and more, process is how the elements of both, where a person does some part of the process and systems or technology does other parts, such as “balance checking account”.

Process requirements can be documented and represented in many forms.

Use cases are a popular technique for process definition, but other techniques such as user stories, process flow diagrams, or workflow models are equally if not more, useful depending on the need for documentation audience.

Whichever techniques you use for requirements, the processes and use cases identified in those requirements On named with a verb phrase: verb and noun, Where the verb is the transformation activity being performed, and the noun as the thing or piece of data being transformed.

In technology based processes, the documentation assures that modules and methods talking to the computer can access the right data, perform the right calculations, print reports, display screens, or correctly transmit information needed.

In Manual process is, documentation gives the people who will be performing those activities, an idea about what needs to be done, what steps to take, and what data to access or provide.

It also helps with actor identification, data calculations, and error or business rule checking.

Requirements – External agents and actors

An external agent is the first person, organization, or system identified in requirements.

Typically identified during the very early scoping part of the project, external agents are those with which the business area interacts.

External agents are the provided or given information within the scope of the project will solution.

Actors, Typically identified later in the process, are defined at the solution level.

Actors all people, systems, or devices that directly interact with a system or solution, but act as are all with external to the system.

In the requirements, act as a name for their roles or with a generic title of the responsibility being represented – no actual names or specific people.

Actors become significantly more important in business analysis at the point where solution requirements are getting specific and more detailed at the functional and nonfunctional levels so that technical options and requirements can be effectively identified. An actor information, reviewed in context with their specific stakeholder and solution requirements, is critical to identifying in building up the specific interface is needed by the actors, as well as defining any security access requirements.

Actors interact with systems or solutions for an interface of some kind. Technical interfaces have different forms of implementation, and depending on the complexity of the interface, the requirements needed in order to effectively designed and developed it vary.

Systems or devices always interact with solutions by using electronic interfaces, however, our human friends may have more diverse interface requirements!

Core component requirements related to actors and agents into references to process is they perform, date of a transform, and the business rules that governor constrain their actions. Actor requirements are typically functional requirements and should outline information about the following:

  • The screens and reports they need to see or use
  • Data of concern
  • Validation requirements for their data, specifying what is or is not acceptable based on their role or any events
  • Instructions needed by the actors for how to use the system (usability), or guide them in changing what they will do after the solution is implemented (transition requirements)

If you find yourself immersed in interaction or usability design concerns, turn to the experts – design engineers, product designers, and human factors engineers or have a specialty in psychological science or human computer interaction, and therefore can be great advisors or advocates for good interaction design as well as being experts on what NOT to do!

Jump On Over To Part 5 HERE!