Last updated on March 19th, 2021 at 07:55 am
Stakeholders dislike repeated questions about their needs. They do not separate the details from the HLRs. But all is not lost. They do like being in on the sessions of project planning especially when they have a stakeholder role in it. Eliciting and organizing these HLRs to form a list of topics like the data exports, imports, UIs, automated functions, etc form the basis for further stakeholder discussions.
The following need is a good example:
Ex: Each Customer record must be assigned a unique identifier.
While this is valid need it is not an HLR and should be noted but does not form an essential requirement of the project statement.
Let us explore how to keep those HLRs at a high level.
1. User story Vs the ‘Shall’ statement:
The ‘Shall’ statement is a formal single-sentence HLR. Agile uses a user story. The difference between the two is in the way the Agile or waterfall ecosystem manages them. HLRs are expected to be from the elicited SME stakeholder’s conversations and should be signed off by the stakeholders and used throughout the project’s life.
Agile uses user stories and a story backlog from the product owner. New stories can be written and a story has relative value on the story backlog with the highest-valued on top. Stories are to be refined by the PO’s contributions.
2. BI system capabilities:
The BI system supports
- UIs
- Data Exporting/Importing
- Automated Functions
- Reporting
An effective proper HLR should include the stakeholder need in the above areas and each represents a topic. The topic conversations discuss the detailed requirements of each phase and should involve SMEs who can support the process.
3. Reports with HLRs:
Reports are akin to a snapshot of the current data in the BI system. The HLR should contain the name of the project, the purpose of discussion, its audience, etc.
Details like the ones below should be left-out of HLR discussions and form a part of detail requirements:
- Data sorting, grouping and selection criteria.
- Triggering/scheduling reports.
- Pagination and layouts.
- Details of delivery.
This conversation with the SMEs is sufficient to make a report with HLRs on data.
4. Exporting and importing:
Data is in ‘machine-readable’ format and HLR discussions should establish answers to queries on
- Name of the process.
- Its data objectives.
- Whether the data expects real-time or background process responses to requests.
- The data needs of the person/system.
- The type of data involved as a primary entity.
This conversation with the SMEs is sufficient to make a report with HLRs on the exporting or importing of data.
These should be left out.
- Criteria for data selection.
- Sorting, summarization, file format, record layouts, and naming conventions.
- Responses and real-time request parameters.
- Value transformation, import data field-level validation, and error reporting.
- Background job scheduling/triggering.
- UI for exporting/importing.
5. User interfaces:
The HLRs should address these important UI topics.
- Activity or business process.
- User types.
- Primary entities in data.
- Any specific or selected instance.
User types are recognized as organizational roles. The answers to the above topic are to be used for the HLR statement. What is not to be included are
- Data-fields for a list of one/all records.
- Field layouts on a screen.
- Invoked actions.
- Navigation Options from record to other screens.
5. Automated HLRs:
A BI system can be automated ‘programmed’ when deriving data is required of it. The following conditions should be met.
- The data is available in the BI system.
- The logic and rules of manually programming the function are described aptly by the SME/ Manager
- The ‘translated’ description can be a computerized function.
The HLR statement should necessarily name the function as with a manual process, indicating the schedule for its performance and its triggers. Leave out from the discussions
- The logic of the function
- The record fields updated or added.
- Triggering parameters details.
Conclusion:
Agile practices differentiate between details and requirements. It is vital that time is not spent unnecessarily in recording details instead of requirements. The four areas where one must keep certain factors in mind while recording HLRs are discussed to ensure that a high level is maintained in recording the HLRs.This is vital to Agile objectives and methodology.
If you are interested in learning more about Agile courses and HLRs, do a course at Imarticus Learning to bolster your practical Agile experiences and improve team productivity.
