[1] -Glossary in enterprise architect: When double click on the baselined file, it compares the last updated models with the saved baseline
Objectives
The key objective of the procedure is to
plan, gather, and document the software requirements.
Inputs
|
No |
Input |
Coming from/Output Of |
|
1 |
Approved Requirements
Elicitation Plan |
PD_Requirements_Planning_Procedure |
|
2 |
Impact Analysis document |
Pre Sales team/ Business
development team/Commercial team |
Activities
|
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
|
1.
|
Create Project Landscape -Guidelines: Create Start Page includes
all production life cycle in the EA file. |
PO |
|
EA
Startup page. |
EA/AzureDevOps |
|
2.
|
Identify the system boundary in case of
multi modules or to control the solution operations to be in the domain
scope. |
PO |
Client statement |
System
boundary |
EA/AzureDevOps |
|
3.
|
Study the solution from the following
perspectives: ·
Business domain ·
Standards ·
Competitors ·
PERSONA’s values ·
Top 3 products in the same domain |
PO |
Client statement |
EA Analysis models for all Important features |
EA/AzureDevOps |
|
4.
|
Study what to be provided as an edge for
our own solution rather than the previous market surveys for relevant
solutions |
PO |
Client statement |
EA Analysis models for all Important features |
EA/AzureDevOps |
|
5.
|
Define interview questions models: ·
Pyramid ·
Funnel ·
Diamond |
PO |
Client statement |
EA Analysis models for all Important features |
EA/AzureDevOps |
|
6.
|
Identify integration needs between the
current proposed solution and the others implemented solution within the
organization |
PO |
|
Related
Boundaries |
EA/AzureDevOps |
|
7.
|
Identify requirements sources for each
domain knowledge on customer side |
PO |
|
|
EA/AzureDevOps |
|
8.
|
Identify and Record: 1-
Functional requirements. 2-
Non-functional requirements (Quantitative) 3-
Digital Transformation requirements (Quantitative) |
PO |
Requirements
Elicitation Plan |
Identified
Requirements |
EA/AzureDevOps |
|
9.
|
Identify the current system workflow
throw activity diagram in order to have a global vision of the software. The current system may be software or
paper work system. |
PO |
Defined boundaries |
System
work flow |
Use case models Activity
diagrams |
|
10.
|
Identify required content and its format |
PO Scrum
Master |
User
stories |
Identified contents |
EA &
AZUREDEVOPS |
|
11.
|
Start in the content preparation and
send the final version to the PM to distribute it. |
Scrum
Master Suitable
resource |
Identified contents |
Content with the specific format |
EA/AzureDevOps |
|
12.
|
Develop and document
software and hardware interfaces if needed |
PO |
Project
Scope |
Identified Goals and requirements |
EA/AzureDevOps |
|
13.
|
Develop and document list
of associated product documentation and training material |
PO |
SRS |
|
|
|
14.
|
Develop and document
acceptance criteria |
PO |
SRS |
|
|
|
15.
|
Approve requirements from Requirement
provider |
PO |
EA
Model |
Requirement approval |
E-mail Or Signature Or MOM |
|
16.
|
Create Traceability profiles for: -
Requirements Vs Usecases completeness -
Persona_UseCases -
UseCase_Class Mappings |
PO TL |
EA
Model |
EA Model |
EA
Model |
Outputs
|
No |
Output |
Going To/Input Of |
|
1. |
Approved user stories Enterprise Architect repository(File/URL) |
PD:02-Requirements Validation Procedure |
Implementation
Guidelines
|
S# |
Guidelines |
|
1. |
Create start page from EA done by creating
a model and set it as default from the diagram menu item. |
|
2. |
System boundary identification: That will help you to know the related
operations and object related to the subject. It will be the container for the use
cases to differentiate between the related and unrelated business areas. Ex: Maintenance operation Stock operation. |
|
3. |
Integration needs identification: That also will help you to classify your
processes where to put if you will implement for both systems. |
|
4. |
System goals are the answers of: why we
need to develop this system? In order to clearly state the system
goals, you should ask the client: what you need and why, Where the "what
questions" have no "why" counterpart's .i.e. they are the main
goals of the system. The goals identified by the answers to what we need
questions should be clearly and properly stated, complete, consistent with
each other, implement-able and testable. |
|
5. |
Identify current system workflow : This will help to define current system
bottle nicks and re-engineer the current process in your system, so you have
improvement opportunities in your solution. |
Inputs
|
No |
Input |
Coming from/Output Of |
|
1 |
Approved
user stories Enterprise
Architect repository(File/URL) |
PD: 01-Requirements Elicitation Procedure |
Activities
|
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
|
1. |
Assess
EA Models to ensure that it meets the required qualities. For
example, should be complete, unambiguous, consistent, etc. Using
the reviews and traceability matrixes will support that. |
TT (and Customer) |
EAand Traceability Matrix |
Identified Defects |
|
|
2. |
Confirm
traceability and ensure that all formalized requirements are traceable to
higher requirements. |
TT (and Customer) |
SRS and Traceability Matrix |
Identified Defects |
|
|
3. |
Identifying
inconsistencies between project’s work products and requirements. |
TT and customer |
SRS and Traceability Matrix |
Identified Defects |
AZUREDEVOPS,MTM |
|
4. |
Document
findings in a deficiency report. |
TT (and Customer) |
Defects |
Defects Report |
AZUREDEVOPS,MTM |
|
5. |
Assess
the reported defects to classify and assign priorities to it. |
TM |
Reported Defects |
Assessed Defects |
AZUREDEVOPS,MTM |
|
6. |
Delegate
defects that have to be corrected to the analyst to solve. |
TM |
Assessed Defects |
Delegated Defects |
AZUREDEVOPS,MTM |
|
7. |
Correct
the delegated defects and report the type of the defect. |
AN |
Delegated Defects |
Updated SRS and Updated Defect Summary
Report |
AZUREDEVOPS,MTM |
|
8. |
Close
the corrected defect. |
TM |
Defect Summary Report |
Updated Defect Summary Report |
AZUREDEVOPS,MTM |
Outputs
|
No |
Output |
Going To/Input Of |
|
1 |
Baselined
EA repository |
PD:3-Requirements Analysis Procedure |
Inputs
|
No |
Input |
Coming from/Output Of |
|
1 |
Baselined EA repository |
PD:02-Requirements Validation Procedure |
Activities
|
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
|
1.
|
Examine System type that direct the
level of complexity and detailed requirements and may be a source of new
requirements |
PO |
Initial
User stories |
Final
User stories |
UML repo |
|
2.
|
Examine user stories (structured
requirements) to classify the difficulties. By Review and identify
traceability to ensure that each requirement is traced back to at least an
identified high-level requirement (use case). |
PO |
Initial
User stories |
Final
User stories |
UML repo |
|
3.
|
Group related user stories in
EPIC/features to detect feature list. |
PO |
Final
user stories |
Features
list |
UML repo |
|
4.
|
Examine non-functional requirements for
each user story. Ex: performance, response time,
connectivity, accessibility, and usability In addition, you can generate new type
of requirements according to your needs. |
PO, QC,DEV |
UML
repo |
Updated
models |
UML
repo |
|
5.
|
Create solution glossary[1]
in order to clarify: ·
Business domain terms ·
Technical Terms ·
abbreviations will be used in your models |
PO |
Final
user stories |
|
UML repo |
|
6.
|
Create BPM using BPMN to represent the
business workflow if needed. This is to examine business workflow of
the overall solution using activity diagram. |
PO |
Final
user stories |
BPM |
UML repo |
|
7.
|
Create use case models for determined
user stories. |
PO |
Final
user stories |
Use
case models |
UML repo |
|
8.
|
Determine users will interact with the
system operations and the relations between them. That will help you to find a set of
security issues and prevent duplication of data. It should be modeled into Actors and use
the actor relation (generalize). |
PO |
Documented use cases |
Determined
actors |
UML repo |
|
9.
|
Determine each operation: ·
Pre-conditions ·
Post-conditions ·
Scenario ·
Exceptions. ·
Triggered by and trigger type (On the relation arrow) |
PO |
AZUREDEVOPS |
Use
cases format in UML project |
UML repo |
|
10. |
Apply required modifications for
internationalization |
PO |
|
|
|
|
11. |
Draw a wireframe prototype to align with
expected scenarios and review with testing team. You can create it using the following
scenario: ·
BPM as menu items/slide menus ·
Use case object name as screen ·
Use case operations as buttons/menu items ·
Object attributes as fields on the screens ·
All available classes use-cases and operations should
have a triggering UI elements (Button, hyperlink, menu item,etc) |
PO,UX |
Wireframe |
EA
wireframe |
UML repo |
|
12. |
Convert use case model/ scenarios to
activity diagrams in order to: -
Represent solution workflow -
Represent the flow/order of each use case diagram -
Represent the complicated scenario activities and
different paths. You should have at least one model per
each use case model Also you can have multiple activity
diagrams for complicated use case scenarios. |
PO |
Use cases format in UML project |
Activity
Diagrams |
UML repo |
|
13. |
Find Missing scenarios that depends on
each other’s |
PO |
Use
cases format in UML project |
Use
cases format in UML project |
UML repo |
|
14. |
Find data model and class
diagrams that will be used in realizing the operations. You can find it by searching for nouns
related to your system boundary. Noun may represent table name or
attribute of the table, so it need rational. |
PO |
Use cases format in UML project |
Class
diagram for data model |
UML repo |
|
15. |
Draw simplified UI (Mockup) models that
realized the analysis models, with attaching each UI element to its relevant
Use case model. |
PO,UX |
EA |
|
UML repo |
|
16. |
Enhance UI, mockups to enhance data
visualization best practices according to: ·
Let data tell the story ·
Keep it simple ·
Use colors according to color mops ·
Drive the focus to required info ·
Say it with pictures |
PO,UX |
EA |
|
UML repo |
|
17. |
Classify results as follow: ·
System Objects ·
Object attributes ·
Object Lifecycle ·
Object operations ·
Object predefined filters ·
Object Custom filters ·
Object Reports and measures interval for each level: o
Daily o
Weekly o
Monthly o
Quarterly o
Yearly o
Occasionally ·
Comparative reports and measures ·
Solution pivots(crosstabs), Dashboards ·
Security o
Who can access o
How to prevent attacks o
How to prevent misuse ·
Logs ·
Integration to other modules ·
Tabs |
PO |
|
|
UML repo |
|
18. |
Define measurements and dashboards for
the following: -
Each object instance (record) measures -
Each Objects overall measures -
Relational measurements -
Cross relations between object attributes (like join date
and left date) -
Cross relations between objects (Like relations between
sales and sales and seasons) -
Define correlation between attributes and objects -
Define forecasting model -
Visualization of analytics and dashboards |
PO |
|
|
UML repo |
|
19. |
Verify objects definition with standard
definition. |
PO |
|
|
UML repo |
|
20. |
Document Object states and its conditions
using state chart diagram to represent the different states for the object if
needed. This phase enriches the model, and
assure completion of the states and add additional behaviors. Also in, include the mapping between the
state and the implementation class operation that cause the state. |
PO,Scrum Master |
Class diagram |
State
chart diagram |
UML repo |
|
21. |
Find requirements conflicts and
testability issues. |
AN,QC Rep |
AZUREDEVOPS |
Identified
Conflicts |
UML repo |
|
22. |
Negotiate conflicts with relevant
stakeholders to resolve conflicts and ensure the identified requirements are
complete, correct and reflect the customer needs. |
PO QC Team Product Owner |
UML
repo |
Updated
UML repo |
UML repo |
|
23. |
Make Suitable Updates according to
feedback |
PO |
|
Updated
UML repo |
UML repo |
|
24. |
Communicate with customer and resolve
any issues. |
PO |
UML
repo |
Updated
UML repo |
Emails |
|
25. |
Baseline requirements and analysis mode. |
PO |
UML
repo |
Updated
UML repo |
UML
repo |
|
26. |
Obtain customer/Requirement provider
approval of the base-lined requirements. |
PO |
UML
repo |
Updated
UML repo |
UML
repo |
|
27. |
Obtain Team commitment to requirements. |
PO |
UML
repo |
Updated
UML repo |
UML
repo |
Outputs
|
No |
Output |
Going To/Input Of |
|
1 |
Enterprise architect repository |
02-PD_Arechticture_Design_Procedure |
Implementation Guidelines
|
S# |
Guidelines |
|
1. |
The relation between requirements
may be by the same actor, pre-conditions-post conditions. |
|
2. |
It will help you to
generate the system test cases. If you have a default
behavior, you should document it once and then refer to it. Ex: Look up tables. |
|
3. |
You should select your
work products according to the project type and CM plan. Ex: We contact the vendor. You need here a vendor
object if it is related to your business. In addition, you need a
class for vendor contains the “Contract” operation. |
|
4. |
Ex: Opened TXN-Approved
TXN-Posted TXN You should model the state
chart diagram for these states and its conditions. |
|
5. |
Ex: You can find conflicts by: -Requirement to requirement
matrix If there is a conflict between requirements. -user to Requirement Matrix
If there is a conflict between users in the same requirement. |
|
6. |
It is a must activity in
case we found conflicts to be negotiated. |
|
7. |
This team is the people who
will carry out the activities necessary to implement the requirements. It may be also the internal
KOM in PM process. -Attendance of QC team is
very important in order to: 1. Find the missing
scenarios 2. Add validations and
business rules needs 3. Define expected
exception 4. Looking for usability
and user experience |
[1] - Applications types may be:
|
Application Type |
Description |
Example |
|
TPS |
Transaction processing system. collects, stores, modifies and retrieves all information about transactions in an organization. |
|
|
MIS |
Management information system. It Supports middle level in monitoring and controlling decision making and administrative activities. The data which is available through MIS is summarized and presented in concise reports on a regular basis. MIS is a primary level of decision making whereas DSS |
|
|
DSS |
Decision support system. It’s an improvement of the concept of MIS. DSS focuses more on leadership. It is all about senior management in a firm providing innovative vision. So it focuses on decision making |
BI Tools Model driven DSS Knowledge driven DSS Document driven DSS GSS |
|
GSS |
Designed for groups, while DSS designed for individual. |
|
|
ES |
Expert system |
|
[1] - you can do that by the following steps in EA:
a. Go to project->Glossary-> right click for create new item
b. When exporting the models, glossary checkbox should be selected in order to be exported
[1] -International standards main areas:
· Font
· Writing direction
· Translation
· Currency
· Date
· Measurements
· Vacations
· Environmental
· Calendar
[1] -Wireframe on enterprise architect:
[1] - In order to increase understanding with relevant stakeholders (Client, QC and implementation team),
[1] -Color map means the usage of the color in the culture to represent facts, for example:
· Red for risk, late tasks
· Green for healthy things, like succeed or finished
· Yellow: for intermediate status, like hold, postponed, in progress tasks
· Do not overuse the colors in mapping
[1] -Object matrix should include:
[1] -Measurements can be:
|
S# |
Measure/Level |
Object |
Instance |
Relation |
|
1. |
Arithmetic mean |
|
|
|
|
2. |
Harmonic mean |
|
|
|
|
3. |
Geometric mean |
|
|
|
|
4. |
Weighted mean |
|
|
|
|
5. |
Mode |
|
|
|
|
6. |
No. Values below average Salary |
|
|
|
|
7. |
No. Values Above Average Salary |
|
|
|
|
8. |
Min Values |
|
|
|
|
9. |
Max Values |
|
|
|
|
10. |
Values Ranges |
|
|
|
|
11. |
Salary Deviation |
|
|
|
|
12. |
CV% |
|
|
|
|
13. |
Variance between Min and Max |
|
|
|
|
14. |
Top n Max start from |
|
|
|
|
15. |
Top n Min End With |
|
|
|
|
16. |
Skewness |
|
|
|
|
17. |
Kurtosis |
|
|
|
|
18. |
No. Extreme upper values |
|
|
|
|
19. |
No. Extreme Lowe values |
|
|
|
|
20. |
Correlation model |
|
|
|
|
21. |
Comparative reports |
|
|
|
|
22. |
Trends |
|
|
|
|
23. |
Dashboards |
|
|
|
|
24. |
Hypothesis models |
|
|
|
|
25. |
Forecasting model (Regression) |
|
|
|
[1] -Standard includes:
· Object Naming convention = Module Name + Object
· Attribute Naming Conventions
· Attributes standard attributes: Creation Date, Created by, Transactional, Status
· Object Standard Details: All transactions should have attachment tab
· Define object required security
[1] -Conflicts means unmatched requirements on the business or between user’s requirements, for example 2 functionalities process in different ways.
In addition, the same requirement is differing between two users.
[1] -Testability means the answer of: what do you expect from the system, it should meet the following:
-expected scenarios [main and alternative] steps outputs, whatever, notification or the real result
-Pre and post conditions
-Expected business rules
-Expected UI
[1] -Glossary in enterprise architect: When double click on the baselined file, it compares the last updated models with the saved baseline