[justify]Accion, Honey Lynne C.
BSCS-3
[color=red] On the given scenario where the system professional, John Juan proposed for a new information system to the manager of a department seems an encouraging move to technological advancement. So I come to appoint of understanding that John Juan is merely concerned on the performance and efficiency the system will brought to its users. At the part of the manager, I can say that he is just afraid that the proposed system will not turn out well so that is why when I have read this, I observe that the manager’s replies seems not confident at all or he seemed ungrateful of the ideas summoned to him but then I also find his considerations. Since in their conversations the initiator is vocal to what he must put focused on before implementing the system might be one remarkable step he done to impress his client. Open communication between the developer and the user is in fact one thing needed to make a successful system to which applied by both parties in the given scenario. This aspect is very important because they help each other, in connection,
We can say that the system is being planned well and people under are in big preparation. The manager stated there that he will be more comfortable if they would first start on the system’s requirements before going on the other way. Requirements are one crucial thing that the systems professional must acquire since the user knows or they had more knowledge with their business and what would probably be the needs of their system. Though we can say that they don’t exactly know the inner doings of the system but then they are those who mostly use it and developers are just the one who made it. Developers when being defined are concerned on the technical side while user from its name itself is concerned on the interacting capability of the system. The manager may be sudden on the impact of failed system presented to him in the past but then I find that he did not even close his mind to the possibility of having a new system. New system is an advantage to a certain business when improvement and proficiency is concerned. Many companies right now intend not to risk their business for new system because they are aware of such circumstances that might happen when it will fail. For me, you will not be a good businessman or an excellent manager if you choose not to risk and just sat down when tomorrow is already ahead of you. Truly, you cannot avoid that issue when you are in a competitive world and I must say that users now a day seem highly proficient when it comes to computer and this is just the only way people is encourage to adapt new technological advancement for their system and also by that their daily business activity will not be that much harder or would prone to headaches. In this way I can guarantee that the two people in the given scenario is well groomed on what is exactly happening in the real world. For the manager, he is just concerned for the welfare of his workers and for the company’s progress which is a contributing factor of his excellence as the manager of a company. Why may I say this?
In fact the manager is not just concerned of his money but also the people under his organization to which is the reason of his being aware of such worn out issues. He seemed to query about everything along the line and also he seemed doubtful at the systems professional capability. But then that is not the thing developers would be insecure of because still the system would rely on its user otherwise the system will be unsuccessful.
You will observe from what I define about the two people involve in the scenario is that their purpose is mainly for the goodness and growth of their company which is a great step towards handling business matters. I consider their way of interactions as formal and well appreciated since they both listen to each others views and opinions with regards to how will they going to start the system. So because they started their conversations as being informative for sure they can work on things well. Somehow we can say that they both believe that they find each others help and I also think they were to find things on them as a person of how they are prepared when issues like this happens and how they will accompany it. I just can not imagine when people in a business were not as open as this given scenario because mostly things turn ineffective if this happen. I also learn more things with regards to what would be the specific methods a manager or user and the systems professional or the developer may have to say that they strictly comprise the assurance of having the things they are needed for the implementation. By undergoing requirements, I can say that it is a good example of how both parties will start their system. So to mainly understand it, I refer to a certain reference: http://en.wikipedia.org/wiki/Requirements_analysis[/color]
[color=green] Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional.[/color]
- [color=red]I may say that when having a requirements analysis we can foresee certain things that is well implemented and those constraints that somehow needed to be solve and given importance. You might be confused of what functional and not functional requirements are which is mainly stated under the requirements analysis. So to basically understand what these two term mean, still I use the same reference of defining it.[/color]
[color=green]Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design.[/color]
- [color=red]Having the functional requirements in lined with your system is a big help on determining of how a system is supposed to accomplish or do as mainly stated there. When the manager and the developer pointed this out, it will really be a good way of understanding the flow of your new system. [/color]
[color=green]Non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions
In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements," and "non-behavioral requirements."[1] Qualities, that is, non-functional requirements, can be divided into two main categories:
1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system. [/color]
- [color=red]From the above description of what a non-functional requirements, it stated there that this kind of requirement somehow focused on the qualities of a system. With that certain aspect I observe that it mainly pointed out on its capability to which it’s concerned relies if the systems actions are in proper and the security it offers is well apprehended.
Aside from that there are also certain requirements aligned, that is also part of the requirements analysis. These are the following:[/color]
[color=green]Customer Requirements
Statements of fact and assumptions define the expectations of the system in terms of mission, objectives, environment, constraints, measures of effectiveness, and suitability. The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:
• Operational distribution or deployment: Where will the system be used?
• Mission profile or scenario: How will the system accomplish its mission objective?
• Performance and related parameters: What are the critical system parameters to accomplish the mission?
• Utilization environments: How are the various system components to be used?
• Effectiveness requirements: How effective or efficient must the system be in performing its mission?
• Operational life cycle: How long will the system be in use by the user?
• Environment: What environments will the system be expected to operate in an effective manner?
Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.
Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.
Derived Requirements
Requirements are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.
Allocated Requirements
A requirement is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.
[/color]
- [color=red]The system requirements specified is also must be determined in the list of your requirements since this will come forth on introducing a new unified system. To which developer and user should correlates with each other since this is regards to the achieving mechanism of your developing system.[/color]
[color=green]Requirements analysis issues
Stakeholder issues
Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:
• Users do not understand what they want or users don't have a clear idea of their requirements
• Users will not commit to a set of written requirements
• Users insist on new requirements after the cost and schedule have been fixed
• Communication with users is slow
• Users often do not participate in reviews or are incapable of doing so
• Users are technically unsophisticated
• Users do not understand the development process
• Users do not know about present technology
This may lead to the situation where user requirements keep changing even when system or product development has been started.[/color]
- [color=red]I agreed with this fact because some researches I have done always answered that these are the certain issues happen why there is a delay of gathering all the needed requirements. To which many things are affected such as the time that system must be finished and the goal of acquiring the expected result being asked by the user.[/color]
[color=green]Engineer/developer issues
Possible problems caused by engineers and developers during requirements analysis are:
• Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
• Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
• Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.[/color]
- [color=red]These fact is mainly true when it comes to the developer. Since user requires the developer to make system like this and that, the developer should mainly follow it because we all know that the clients are the one who will use the system. If for example developers does not have that constant communication with the user, for sure two things will occur: (1) The developer will still implement the system to what he or she believe will help in which when delivered to the user, the user will say it does not do what they wanted. So the system just turned out a waste. (2) The system will be kept on modifying since they don not have the thorough needs or requirements of the user.[/color]
[color=green]Attempted solutions
One attempted solution to communications problems has been to employ specialists in business or system analysis.
Techniques introduced in the 1990s like prototyping, Unified Modeling Language (UML), use cases, and Agile software development are also intended as solutions to problems encountered with previous methods.
A new class of application simulation or application definition tools have entered the market, these tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:
• electronic whiteboards to sketch application flows and test alternatives
• ability to capture business logic and data needs
• ability to generate high fidelity prototypes that closely imitate the final application
• interactivity
• capability to add contextual requirements and other comments
• ability for remote and distributed users to run and interact with the simulation[/color]
- [color=red]There are attempted solutions that are mainly identified above. I can say that this is concern of the requirement specification needed to be presented for both parties. Since the user does not really know the flow when technical issues are being shared, developers must incorporate to their users its meaning. But then, developers must just point out the scope that is needed for the systems requirements, while coding and other schemes, will remain on the developer since they are only the ones who could barely understand it.
We can merely say that John Juan, the systems professional and Peter Pedro, the manager undergo many levels before going to the other way. The manager’s requirements being planned address to different kinds of problem where he also needs the presence of the system professional since the developer know most of the inner functions of the system. To which is an advantage with them since the manager knows the inconsistencies of his system while the developer will just mainly interpret its lack to the user. By then, they can both compromise what would be sustained and elicited on the old system.
I may say that it does not matter of how large a system is, as long as the users needed requirements are settled up because that is just what the developer will depend on when he will be starting doing the system. The capability or skills of the developer is also being prioritized since they will do on the coding and structural design of the system. Without their expertise how may they acquire the specific requirements needed by their user when at all they don not know how exactly it is to be done. Another issue will rise again, so that is why manager should require developers that are mainly expert in the field of technology.
I also research the system requirements which will also be helpful for incorporating a system. These is its reference: http://en.wikipedia.org/wiki/System_requirements[/color]
[color=green]Recommended system requirements
Recommended system requirements are often suggested by software vendors for optimal performance of software. Although not a necessity, this set of requirements is often sought after by power users who expect to gain a better experience of software usability. Recommended System Requirements do not promise best possible performance of software and are treated as more of a guideline than a rule. Almost always a better system is available, or will be in future, to provide better performance. Also, exceeding by far these requirements does not guarantee to the user that everything will run with absolute smoothness and look its best. More often than not, games are a bit disappointing in this respect, presenting issues that may or may not be corrected with future modifications.
Hardware requirements
The most common set of requirements defined by any operating system or software application is the physical computer resources, also known as hardware, A hardware requirements list is often accompanied by a hardware compatibility list (HCL), especially in case of operating systems. An HCL lists tested, compatible, and sometimes incompatible hardware devices for a particular operating system or application. The following sub-sections discuss the various aspects of hardware requirements.
- Hardware requirements are basically important since it will be needed for the implementation of your system. For sure all business company have it and through hardware, the system usability will be tested.
Software requirements
Software Requirements deal with defining software resource requirements and pre-requisites that need to be installed on a computer to provide optimal functioning of an application. These requirements or pre-requisites are generally not included in the software installation package and need to be installed separately before the software is installed.[/color]
- [color=red]Having a software requirement is also one thing that must be pointed out especially if you are doing a system, software is mainly the inner tool use while the hardware is mainly the physical or the device being utilize.
Since we thoroughly learned a lot of things in rely to the systems requirements, we can now possibly say how the user and the developer would correspond to their planned system. With that, no worries will happen as long as both parties constantly communicates and things are being deliberate well.
[/color]
my blogsite: http://cshoney017.blogspot.com/
[/justify]
