Home' Trinidad and Tobago Guardian : May 7th 2013 Contents B6
Guardian www.guardian.co.tt Tuesday, May 7, 2013
The ANSA McAL Group of Companies invites
applications for the position of:
Heading the newly established Real Estate Division, the suc-
cessful applicant will be an experienced, professionally trained
Property Manager. Responsibilities will include property devel-
opment and oversight of the maintenance function.
As such you will be required to lead projects, manage costs and
design and implement effective administrative systems while
establishing productive relationships with relevant authorities,
architects and other key industry stakeholders.
The position requires an appropriate Property Management
&/or Engineering designation and at least five (5) years expe-
rience in a similar position.
• Property Management and/or Engineering designation
• At least five (5) years experience in a similar position
• An Architectural qualification will be an asset
A competitive remuneration package with other Group
Benefits is being offered. Interested individuals should submit
their applications by May 13, 2013 to:
Clearly agree on what you're going to deliver
From Page B5
You can use several methods to
understand and capture these require-
Here, we give you four techniques:
Technique 1: Using stakeholder
Talk with each stakeholder or end-
user individually. This allows you to
understand each person s specific views
Technique 2: Using joint interviews
or focus groups
Conduct group workshops. This
helps you understand how information
flows between different divisions or
departments, and ensure that hand-
overs will be managed smoothly.
When using these two methods, it s
a good idea to keep asking "Why?"
for each requirement. This may help
you eliminate unwanted or unneces-
sary requirements, so you can develop
a list of the most critical issues.
Technique 3: Using "use cases"
This scenario-based technique lets
you walk through the whole system
or process, step by step, as a user. It
helps you understand how the system
or service would work. This is a very
good technique for gathering functional
requirements, but you may need mul-
tiple "use cases" to understand the
functionality of the whole system.
Technique 4: Building Prototypes
Build a mock-up or model of the
system or product to give users an
idea of what the final product will
look like. Using this, users can address
feasibility issues, and they can help
identify any inconsistencies and prob-
You can use one or more of the
above techniques to gather all of the
For example, when you have a com-
plete list of requirements after your
interviews, you can then build a pro-
totype of the system or product.
Step 3: Categorise Requirements
To make analysis easier, consider
grouping the requirements into these
Functional Requirements -- These
define how a product/service/solution
should function from the end-user s
perspective. They describe the features
and functions with which the end-
user will interact directly.
Operational Requirements -- These
define operations that must be carried
out in the background to keep the
product or process functioning over
a period of time.
Technical Requirements -- These
define the technical issues that must
be considered to successfully imple-
ment the process or create the prod-
Transitional Requirements -- These
are the steps needed to implement
the new product or process smooth-
Step 4: Interpret and Record
Once you have gathered and
categorised all of the require-
ments, determine which require-
ments are achievable, and how
the system or product can deliver
To interpret the requirements,
do the following:
Define requirements precisely
-- Ensure that the requirements
Not ambiguous or vague.
Sufficiently detailed so that
everything is known. (Project
over-runs and problems usually
come from unknowns that were
not identified, or sufficiently well-
Related to the business needs.
Listed in sufficient detail to cre-
ate a working system or product
Although many requirements are
important, some are more impor-
tant than others, and budgets are
Therefore, identify which
requirements are the most critical,
and which are "nice-to-haves".
Analyse the impact of change:
carry out an Impact Analysis to
make sure that you understand
fully the consequences your proj-
ect will have for existing process-
es, products and people.
Resolve conflicting issues: Sit
down with the key stakeholders
and resolve any conflicting
requirements issues. You may find
Scenario Analysis helpful in doing
this, as it will allow all those
involved to explore how the pro-
posed project would work in dif-
ferent possible "futures".
Analyse feasibility: Determine
how reliable and easy-to-use the
new product or system will be. A
detailed analysis can help identify
any major problems.
Once everything is analysed,
present your key results and a
detailed report of the business
needs. This should be a written
Circulate this document among
the key stakeholders, end-users,
and development teams, with a
realistic deadline for feedback.
This can help resolve any remain-
ing stakeholder conflicts, and can
form part of a "contract" or
agreement between you and the
Step 5: Sign Off
Finally, make sure you get the
signed agreement of key stake-
holders, or representatives of key
stakeholder groups, saying that
the requirements as presented
precisely reflect their needs.
This formal commitment will
play an important part in ensuring
that the project does not suffer
from "scope creep" later on.
Links Archive May 6th 2013 May 8th 2013 Navigation Previous Page Next Page