Juan or Pedro?
Scenario:
Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Based on the conversation above, both parties have good points. As an IT professional John Juan has a point of identifying and reviewing the company’s performance. This would definitely help on determining which aspects of their work should be modified and which should be retained or be developed more. This somewhat relates to our past project which is to analyze an organizations information system needs. After we have done this project I’ve realized that looking back on the development of the company should be the first thing to do before doing any necessary changes on their information system.
On the other hand, based on the scenario Pedro Peter who is the department manager doesn’t want to go back and review the past system and instead just give the necessary requirement their company wants to have and be applied. I know Pedro Peter do have a good point to because it would probably take time to hold back the old system and he insist to have a new one maybe because he wants an immediate new system for their department without any other matters to tackle anymore, just the requirements they would be specifying. There are times wherein an existing system is still able to manage the work of a department or a company and should not be changed at all. This could be a point why the IT professional would want to study the old system of the department.
So were do I stand? Though both Pedro and Juan has their good points on the situation I would agree more with Juan which I think most of my classmates would do as well. As an IT professional you could not just construct a new system especially when it is for a company in just a snap. There are a lot of things to be considered. One is the company’s current and past systems which would help in analyzing which of those past systems worked well for the company and which did not or which type of system would help the company more.
Whom do I sympathize most? It would be the department manager Peter Pedro whom I sympathize more. Why? It is because as a department manager it not just what the departments requirements for a new system that needs to be considered, the needs of the employee maybe and of the whole department should be considered as well. In addition, he could not get all of the necessary requirements of the system if he wont look back on the departments past activities. Pedro Juan should know that it is not just the “wants” of the department that needs to be considered on determining the requirements but the “needs” as well because sometimes the wants are just wants and are not necessary at all. Considering every needs of the department should be first considered.
What method would I suggest they take? I think the It professional should first do an assessment which regards the past system of the company. In this manner both parties would know what development and what impact did the past system did for the department and the company. I could also suggest they do the ISNA (Information System Needs Analysis) as well understanding the business needs and the employee’s needs after understanding and studying their past systems. In this manner they would be then able to identify requirements for the system for they already know the basic needs of the department.
Assessing the past systems includes documenting each system the department had used and the development of those. Then upon identifying each, the use of it should also be considered, whether that system made an impact to the company and helped the company flourish or pulled down the company. This is a process of evaluating and rating which is mostly helped the company. ISNA on the other hand include identifying what the company is, what are their goals and objectives, for whom and what do they function. After identifying these we would know what that company needs to have that would help them progress more. With the help of these methodologies, identification of the system requirements is made easy and accurate.
Other methods that could be of help for this situation are requirements elicitation and requirements engineering which I have learned from our Software Engineering class. To give an overview here is what I’ve got from our lessons in SE regarding requirements elicitation and requirements engineering.
Requirements Engineering
• Requirements Engineering is a term used for systematic approach to acquire, analyze, validate, document and manage requirements.
• Typically implemented as a cyclic or iterative process.
• Requirements validation may include prototype construction and evaluation.
• Applied at both system and software levels, often with interleaved system architecture design.
Requirements Elicitation Principles
• System development is motivated by a problem.
• The aim of requirements elicitation is to understand the problem clearly.
• The problem can only be understood by discovering who or what is affected by the problem.
• Several activities should be covered:
- Analysing the problem
- Identifying requirements sources
- Eliciting requirements from these sources
Requirements Elicitation (Analysing the Problem)
• Identifying goals (project motivation):
- e.g. Problem : The current information system is costly to maintain.o => Goal : Reduce maintenance cost.
- Goals are really very high-level requirements
- The goals are about the problem domain
• Identifying constraints on the solution:
- e.g. retain existing OS look-and–feel
- Resources (time, people, budget) are also constraints
- Goals and constraints should be measurable!
• Defining the scope of the problem (the boundary of the system)
• what is external to the problem (the environment)
• what is internal to the problem (the core of the system)
• Assessing the risks (e.g. financial, technical, etc).
• Estimating an approximate project cost.
Requirements Elicitation Techniques
Some techniques include :
• Interviews
• Observation
• Facilitated meeting
• Prototyping
• Scenarios
In general, requirement engineering also called Systematic requirements analysis according to Laplante is a sub discipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems. While requirement elicitation which is a method in requirement engineering aims to identify and obtain the requirements of a system from the users, customers, and other stakeholders involved.
References:
http://en.wikipedia.org/wiki/Requirement_engineering#Requirements_engineering
http://en.wikipedia.org/wiki/Requirements_elicitation
0 comments:
Post a Comment