I have chosen Funder, Trust Board, Executive committee, Regional Manager, and Volunteer as the actors for Rich Picture for the Youth Action environment. I have chosen them because they play social roles as key actors for organization and they are the people in the problem area. And they are the actors who carry out the systems main activities.
I assume Regional Manager is the person within the situation that I think are important. Regional Manager dealing with the problem of no standard reports from service centres which he/she overseen. He/she is operate service centers in autonomous. And He/she own role of managing the service centers activities that led me to choose as key actor.
In Head Office, Trust Board and Executive committee have conflicts with Regional Manager about to set up system. They also control the charity process. And head office carried out the transformation process of Youth Action. They are problem owner of the environment. If we develop MIS, they will be users. So, Trust Board and Executive committee play key actors in the diagram.
Volunteer and Young people are people work in service center. Volunteer is responsible for running project well and relation with Regional Manager to report. And volunteer also thinking and expected to be vetting process with the Head Office. In the future when we develop system, volunteer will act as user of the system. So, I chose volunteer as key actor.
Funder want report about how well service running and charity is value or not. And funder will be benefit if investment of MIS happens. Because from that system, funder will get make decision well and support necessary data. So, funder has to interrelate within the organization of Youth Action. These important relationships lead me to choose funder as actor in the environment.
A2.2
Conflict areas
In the diagram shown the problem owner is the Head Office. I found that there was conflict between the Regional Manager and the Head Office. There was a real conflict between Head Office and Regional Manager concerning how and what to set up system (hence the crossed swords in the rich picture diagram). And they have also conflict about to reduce overhead.
The people working in service center are Regional Manager, Volunteer and Young People. Currently, service center is conflict with media. Service centers want to keep data accurately and enough space but IT equipment (i.e. the computer shape within the circle) lack of security. Head Office wants to develop MIS but their computers are out of date to achieve their goal.
In the diagram shown crossed swords between Head Office and Funder. I found that there was conflict between the Funder and the Head Office. There was an important conflict between Head Office and Funder concerning question about what projects are value for money. Other conflict is Head office cannot provide necessary report what Funder want.
Key issues
I found that there was issue about to centralized management of services. And Head Office is thinking to investment in MIS. But, Regional Manager is worry about how will centralization affect. Currently, services and projects autonomous run by Regional Manager. He/she thought it is fairly. Other difficulties for Regional Manager are handling service centers (i.e. the building in the right of the picture represents more than one service centers) that make him/her overload of work. That concern about management of service centers by Regional Manager. Formal communication with service centers is report. But, they report different formats so, Regional Manager is thinking about standardized system.
In the diagram, there is important issue that Funder is thinking about to get necessary data. But, Head Office has poor relationship (shown doted-line) with Funder. Head Office cannot provide necessary report about how well projects are running and about budget.
Service centers are run by Regional manager in autonomous. He/she worry about of his/her role when Head Office changes autonomous into centralized the management system. Regional Manager own problem thinking. His major issues include: when system set-up, increase communication and understanding between service centers? That will be major issue after analysis process finish. Regional Manager also dealing with the problem of no standard reports from service centers which he/she overseen.
Head Office of Youth Action thinks to develop in MIS. And they have major issues that they hope a system will help collect necessary data to make decision and efficient management. Head Office hopes to minimize conflicts.
A2.3
In A2.1, I identified issues these are matters which are of concern. These issues lead to consider what the main focus is to resolve in the Youth Action environment. The major issue is that Head Office hopes a system to integrate that will help make decision and to collect necessary data to report Funder. Head Office hopes to minimize conflicts outside and within organization. So the main focus include: building up a good management and provide necessary data securely.
A2.4
In rich picture diagram, I illustrated relationship between actors. These symbols also describe their activities including people, service and information flow. Funder is support Youth Action with contract so, budget is control by Funder. But, Youth Action charity system is control by Head Office. They receive funding with contract (I already shown their relationship in diagram). And they keep and gather information of charity and Funder. Beside, Head Office manages charity running well and provide necessary support include equipments, people, money and data to service centers. The most important tasks are they try to improve vulnerable young people life and better support.
Service centers are control by Regional Manager. In service centers the make request needs and report to Regional Manager. Regional Manager manages service centers including working people and projects going ok. He/she decide what and how to support to service centers and then request to Head Office. Volunteers participate to run project well and have to oversee young people.
B1. Section B- Requirement Analysis using Use Case Modeling
Use Case Diagram for Dig-it Project
B1.1
Primary scenario for Record Group Lists
Use case start when full time worker selects Group Lists screen.
System will display a page.
Full time worker will click arrange new group button from Group List screen.
Full time worker will select young people names from profiles.
Full time worker will type selected young people names.
Full time worker will type group name.
Full time worker will click save button.
System will verify the information and save.
Primary scenario for record volunteer allocation lists
Use case start when full time worker selects record volunteer allocation screen.
System will display an allocation page.
Full time worker will click new volunteer allocation button.
System will display available volunteer names.
Full time worker will selected name of volunteer.
Full time worker will type volunteer name to lead group of young people.
Full time worker will select submit.
Full time worker will type group name.
Full time worker will click match button.
System will match volunteer name with group.
Full time worker will select submit.
The system will verify information, save the information details, use case ends.
B1.2
Secondary scenario for Record Group Lists
Use case start when full time worker selects Group Lists screen.
System will display a page.
Full time worker will click arrange new group button from Group List screen.
System will display available young people names.
Full time worker will select young people names from profiles.
Full time worker will type selected young people names.
Full time worker will select submit.
System will check young people names are exist, if not exit system will display not found record.
Full time worker will click save button.
System will alert save as group name.
Full time worker will type group name.
Full time worker will select ok.
System will check group name is duplicate, if duplicated system will display already exist.
System will verify the information and save.
Alternative paths
Selected name already exist: System will display only available young people names.
Not exist in record: System will display not found in record and redisplay to type.
Forget to name and save group: System will alert save as group name.
Group already created: System will check group name is duplicated, if duplicated system will display already exist and redisplay new arrange group.
There is a case that every time full time worker select submit or save, the full time worker can also select cancel. The system will not verify and the use case ends.
Secondary scenario for record volunteer allocation lists
Use case start when full time worker selects record volunteer allocation screen.
System will display an allocation page.
Full time worker will click new volunteer allocation button.
System will display available volunteer names.
Full time worker will selected name of volunteer.
Full time worker will type volunteer name to lead group of young people.
Full time worker will select submit.
System will check the volunteer name is valid in record. If not ok, will display invalid name and redisplay to type name.
Full time worker will type group name.
System will check the group name is already allocated by volunteer. If allocated, display already exist and redisplay to type name.
Full time worker will click match button.
System will match volunteer name with group.
Full time worker will select submit.
The system will verify information, save the information details, use case ends.
Alternative paths
Invalid name: System will display invalid name and redisplay to type name.
No volunteer: If there are no available in the project, system will show allocation pending status to the group.
Already allocated: If already allocated, system will display already exist and redisplay to type name.
Every time the full time worker can also select cancel. If select cancel, the system will not verify and the use case ends.
B2
B2.1
I chosen full time worker and volunteer, Local Authority, young people and elderly people as the actors for use case diagram. I have chosen them because they are key to the Dig-it system. How I consider? I consider their interaction with use cases, responsibility. And important tasks are relation and performed by these actors. Following are why I chose them as actors and why they are key to the system.
Full time worker is interaction with local authority and volunteer. Full time worker needs to interaction with use cases are add gardens information, add volunteer information and young people information, record group lists, record volunteer allocation lists, record Rota list and record comments. The important tasks volunteer allocation, arrange and record group of young people are performed by this actor. Full time worker is also associated with the proposed system. When we set up a system to record the necessary data and developing the management information system, the full time worker is relevant to that proposed system. So, I decided full time worker as the actor because of above key facts.
Volunteer is interaction with Full time worker and with use cases. The important tasks record Rota Lists and record assign with young people are performed by this actor, volunteer. Volunteer associated with the proposed system, when set up system they need to provide data. So, this actor is represent a role for system.
Local Authority is interaction with full time worker in Dig-it project. Local Authority is responsible for project to give gardens information of elderly people to look after by the project. Local Authority is also associated with the proposed system, to invest money and support additional equipments. Above reasons is why I chose as actor.
Young people are needed to interact with full time worker in record information task. Young people needs to relation with use cases are record their information and assign working with volunteer. So, I have chosen them as key actor.
Elderly people are also interaction with full time worker and relation with record comments use case otherwise record feedback. This task respond by elderly people is important to project. So, I have chosen them as key actors.
B2.2
In primary scenario for record volunteer allocation lists, the main key is to select volunteer to lead group and match volunteer with select group. In this scenario, key activities are to select and type available volunteer name to make allocation, type group name, match volunteer name with group and submit. I assume these are key activities. To make volunteer allocation, firstly we need one volunteer to lead group. So, we need to select and type that volunteer name in display page. Then we need young people group which have to lead by selected volunteer. So, we need to type group name in page. It is ok, but to assign and make sure to know which group is led by which volunteer. We need to click match volunteer name with group name and submit button. Simply, that are how I identified the key activities to include in that scenario.
B2.3
Identifying alternative uses to produce the secondary scenario of record group
By identifying the primary scenario for record group list, there are some issues found.
What if young people name is already selected in previous arrange group?
What if selected young people name does not exist in record?
What if group name already created? What if Full time worker forget save name group?
These questions are to produce the secondary scenario. To identify alternative paths, I consider based on question which come from primary scenario. I have to consider these questions, so problems of selected young people name already exist is solved by displaying only available names. To avoid group name already created and forget to save case, system will check and display alert box.
Identifying alternative uses to produce the secondary scenario of record volunteer allocation
By examining the primary scenario for record volunteer allocation, there are some questions found. To identify alternative, we need to think what if everything is not going fine otherwise error? Following are the how I identify the alternative approach.
What if Full time worker type invalid name or does not valid in record? To solve this, system will display invalid name.
What if there are no volunteer available on the record? The only thing can do is system will show allocation pending status.
What if group name already allocated by another volunteer? If already allocated, system will alert already exist.
B2.4
Assumption
In Dig-it project system, I assume local authority give and support gardens information to full time worker. I assume Local Authority already record elderly people information and keep them with gardens information together. To run project, we need to take young people from different sources, but I assume to record their information details they need to give themselves directly to full time worker. About record assign use case, I assume volunteer is responsible for this and need to record working assign of young people group which he/she led. About record comments use case, I assume full time worker need to ask feedback from elderly people and record them as comments. For purpose of record this is to know project success or not. This record can also be used in report and that will be useful in future.
Some given information in dig-it project is unclear and not enough, so I found questions to get necessary information. I have questions for local authority, in real-world I will ask these: Do you want to invest in IT? Do you have ability to make important decision?
By concern with report, I will ask following questions to full time worker:
How do you provide data to local authority?
Do you need to report to local authority? If so, in that report what data and information include?
About volunteer allocation and other ambiguous, I will ask following:
How do you limit time length of Rota lists?
If there are no volunteers to allocate in project, who will be solve this problem and how?
If one group of volunteer is sick, how do you run this group? Do you replace with other volunteer or postpone?
If feedback is too bad what happen next?
Do you record gardeners' preference group?
If gardeners' want to request again their preference group, how do you respond back?
Who control the project important decision making?
I also have to ask volunteer these question:
If a young person is sick, how do you assign?
If there are social problems happen in group, how do you control?
Do you have power to fire young people?
Following are I found questions about young people and want to ask them:
Do you have ability to reject if unhappy in running project?
Do you have chance to change group?
Section C - Critical Analysis of the tools used
If we develop the information system we need to understand user requirements and consider from different views otherwise multiple views. We need to understand both technical and environment in which the system sits because the two approaches related each other. Good requirements analysis can benefits enhanced quality, increased productivity, reduced time and improved user satisfaction. But, requirements analysis is not an easy process. When we analysis requirements, we faced with problems. By classifying these problems, these problems include two elements "Hard" i.e. technical view and "Soft" i.e. environmental view. To solving these problems, we cannot handle by using one approach. We need to think about not only soft; real world view but also hard; system world view. There is also one point, if we go with two approaches we also need to consider what tools are appropriate for requirements analysis process. Developers need to select appropriate tools to address these social and technical problems and good skill used tools.
Let me discus about soft approach. Soft approach is considering for real-world. So what is real-world mean? Real-world is dynamic and it involving especially people and their interaction, conflicting areas, problems situation, opinions and so on. This approach mainly focuses on social factors and human issues. By case study, we have applied in practice how tools are useful and which tools allow and disallow for requirement analysis. There are different tools available that could be used for soft approach as an example Rich Picture.
To consider from soft approach, we illustrated rich picture for Youth Action environment. I prefer that because simple illustrations, easy to understand, no need to know about any notation and rules. It is flexible and people can understand that simple picture even 50 or 60 years long. By creating Rich Picture, we can address problem situations these are lack of formal status. But I faced problem while drawing rich picture, that I cannot easily track real-world problem situations of Youth Action environment because it has complex organizational situations with many stakeholders. So, it made me hard to get qualified rich picture. But, it helps and allows identifying clearly key issues, key actors and main focus about the environment before the development starts. A simple example part of rich picture is as follows:
Drawing simple picture of people with thinking and speech bubbles linked to them can show problem situations in the current environment that may lead to user requirements. In case study by creating Rich Picture, we knew the information of the organization. So, I assume it is useful for information gather. But, it not shows much about user needs and expectations for the future system. We can draw in rich picture even what people are thinking. As above example shown, regional manager is thinking about standard report. And he/she also worry about how will affect when centralized management system. And these also include issues of conflict, structure, actors, data, and so on. E.g. there is conflict between head office and regional manager about to set up system, because they have different point of view the way to build system. We can also see interaction between actors, and moreover, issues for e.g. in head office that they want to develop Management Information System. These are not concern with any technical problems. To figure out social and issues problems including culture, we need to consider soft thinking about environment in which the system sits.
We drew rich picture in case study because Rich Picture can help interaction between stakeholders and understand complex problems (Checkland). So, we can understand Youth Action environment well. And we can identify hidden requirements of Youth Action. Rich picture helps us to visualize people role in the organization and show up the worries of individuals. Rich picture helps thinking about the problem situation. Then, analysis is done rich picture help to thinking about what can be solve about the problem situation. So, we can avoid design before analysis process. Rich picture of Youth Action environment help me to define problem situations and people roles and their relationship within the problem situation.
But there is a point that to know this we need enough time in analysis process. But also there are some points; we cannot understand functionality requirements of Youth Action and user expectations and needs by drawing rich picture. In soft approach, we hard to find where data flow happen and lack of the detail data is the case. By this approach, not knowing in advance what users want from the future system and what they have to perform tasks in propose system. But other approach do, many tools are available - for example use case.
Hard approach focuses on the technical issues. By hard approach we can look for a technical solution. Requirements analysis by hard approach can understanding the system behavior and functionality. Hard thinking is effective way of thinking about system that use in future. There are different tools that could be used for to consider system behavior as an example Use Case Diagram. In case study, I created Use Case Diagram for Dig-it project. We create Use Case as a requirements analysis tool, to identify the actors, system scope and functional requirements. It helps us to show important relation user and system and system response. Use Case Diagram is effective tool for hard approach because it shows behavior requirements that can help us to create a design form and it show system need to build. Use case tool is valuable for requirements analysis technique.
To complete use case diagram and documentation, we need scenarios i.e. primary and secondary. In case study, I carried out primary and secondary scenarios for Dig-it project. So, I found that scenarios give basis example of future use. And scenarios can help developer to create and visualize design approach. Use Case Diagram shows us clearly of the system boundary. In coursework, it is difficult to visual and defined system scope because we got only a brief description about Dig-it project. In actual world, it is also hard to match the user expectations and needs by only description. For hard thinking use case tools effective because it can be seen from user perspective. And use case notation is simple so easily understand. It can help easily communicate between end user and analyst even without knowing about notation. Use case diagram help us to describe the functionality needed to meet a stakeholder request. A simple example of use case is as follows:
In use cases diagram for Dig-it project, I defined actors such as full time worker i.e. primary actor, volunteer, local authority and so on. These actors play a role when interacting with the system. So, for proposed system use case enable us to identify the actors. By creating use cases, I describe tasks performed by actors and the role of actors for example full time worker performs record volunteer information tasks. I described what system do for the actors to achieve their target. I drew the relation between actors, interactions with the system also including system responses. Use case diagram help to consider about system behavior.
We have problem with use case diagrams is we have already resolved of what system is need to build and already consider about system for example a registration system. So, it is like we need to define the system to be built before analysis and development process. But also to illustrate Use case diagram well, the developer or writer need skill. It is not much flexible. It is right that helps for communication between users and developer but some of relation such as includes and extends are difficult to interpret for the stakeholders or users. To become complete use case, we should describe all scenarios of each use case including all possible alternative paths. So use cases are difficult to visualize and abstract. The main issues are we cannot describe about environment effects and organization factors and their policies in use case diagram. Use case diagram not much tell us details about data flows and actors relationship.
Consideration environment by soft approach, we drawn and use tool as Rich Picture Diagram. Why we need to think about environment? We need to analysis environment that concerns employee needs and issues, roles of people and organization structure. These factors are of importance in analysis and development process. In case study, purpose of creating a rich picture diagram for Youth Action environment is to consider such issues. In some situations, issues cause the formal information system to fail. Understanding environment aspects is essential and our system will have little chance of success. That is why; we should not ignore environment effects.
Requirements analysis also depends upon the technical issues and needs of the system. To looking for a technical solution we also need to good understand of the system behavior and functionality. Hard thinking is effective way of thinking and thinking technically helps us to built system that use in future. Our requirements analysis should describe the functionality needed to meet a stakeholder request or need. So, to achieve success of requirement analysis soft and hard are essential. Finally, I assume a mix of technical and environment make a good requirement analysis.
Let me discuss about the developer roles. It is important part that the developer's role of using the different approaches with critical tools or methods. So the developer needs to consider any collective set as a system epistemological view: in understanding the environment, social and culture, and so on. Beside, the developer also needs to analysis ontological view; hard approach about the system that needs to be built. So, it clear that developer needs to understand the both approaches well. Also these two approaches are related that I already mentioned above. I assume that using both approaches is not only beneficial to the developer, but also necessary and chance to get system success. Good development and requirements analysis will iterate between real world and system world. To build large, enterprise, complex systems we need good requirements analysis of social and technical. To some point, we have ability to separate out the different issues raised by the two approaches. Developers need skill to handle these issues that leads to success. To target a system success, we will look at not only the needs and but also aspirations of the users. So, requirements analysis depends upon good understanding of both the technical needs of a system as well as the environment in which the system sits.
