a.John Juan or Peter Pedro

We obviously observed that both do have different views. What happens is that they don't meet on the same point of view. but as for me, i would choose on John Juan's side because he knows what happens as a system professional. He knows what's best for the system. No matter how professional Peter Pedro is, he doesn't know the exact flow of the system because he only knew how the system helps the company. He doesn't really know the real picture of the process on how it was developed. In analogy, it's just like he can only see the general part of the system. John Juan is the right person that should be given of much attention because he knows what steps should be taken, what risks should arise if 'this or that' action is taken into account. If I have the authority, I will give consider John Juan as a very important person.

The System Requirements Specification (SRS) document describes all data, functional and behavioral requirements of the software under production or development.

This 10-section template covers the overall description of the system/software to be implemented, use cases and scenarios, data model, functional and non-functional requirements, interface and behavioral models, as well as restrictions and validation criteria to be used for the software. The Appendices may include business rules, glossary, traceability matrices and other necessary supplementary information that are specific to the system.

Requirements analysis in systems engineering and software engineering, 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.

Conceptually, requirements analysis includes three types of activity:

* Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
* Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
* Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.

Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems." In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggest that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.

Stakeholder identification
See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are persons or organizations (legal entities such as companies, standards bodies) which have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:
• anyone who operates the system (normal and maintenance operators)
• anyone who benefits from the system (functional, political, financial and social beneficiaries)
• anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product
• organizations which regulate aspects of the system (financial, safety, and other regulators)
• people or organizations opposed to the system (negative stakeholders; see also Misuse case)
• organizations responsible for systems which interface with the system under design
• those organizations who integrate horizontally with the organization for whom the analyst is designing the system
Stakeholder interviews
Stakeholder interviews are a common technique used in requirement analysis. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.
Contract-style requirement lists
One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.
An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.
Strengths
• Provides a checklist of requirements.
• Provide a contract between the project sponsor(s) and developers.
• For a large system can provide a high level description.
Weaknesses
• Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system.
• Such requirements lists abstract all the requirements and so there is little context
• This abstraction makes it impossible to see how the requirements fit together.
• This abstraction makes it difficult to identify which are the most important requirements.
• This abstraction means that the more people who read such requirements the more different visions of the system you get.
• This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil as they say is in the details.
• These lists create a false sense of mutual understanding between the stakeholders and developers.
• These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers use these discovered requirements to renegotiate the terms and conditions in their favour.
• These requirements lists are no help in system design, since they do not lend themselves to application.
Measurable goals
Main article: Goal modeling
Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.
Prototypes
In the mid-1980s, prototyping was seen as the solution to the requirements analysis problem. Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
• Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
• Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
• Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
• Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
• Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.
Prototypes can be flat diagrams (often referred to as Wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.
Use cases
Main article: Use case
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.
Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.
Software requirements specification
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.
Types of Requirements
Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:[1]
Customer Requirements
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). 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:[1]
• 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?
Functional Requirements
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.[1]
Non-functional Requirements
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
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.[1]
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.[1]
Derived Requirements
Requirements that 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.[1]
Allocated Requirements
A requirement that 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.[1]
Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard.
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.
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.
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.
Also, 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



b. as to what method should be taken in action, here are some tips:

1. Problem statement

A problem statement is a clear concise description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve the problem. When bringing together a team to achieve a particular purpose provide them with a problem statement. A good problem statement should answer these questions:
1. What is the problem? This should explain why the team is needed.
2. Who has the problem or who is the client/customer? This should explain who needs the solution and who will decide the problem has been solved.
3. What form can the resolution be? What is the scope and limitations (in time, money, resources, technologies) that can be used to solve the problem? Does the client want a white paper? A web-tool? A new feature for a product? A brainstorming on a topic?
The primary purpose of a problem statement is to focus the attention of the problem solving team. However, if the focus of the problem is too narrow or the scope of the solution too limited the creativity and innovation of the solution can be stifling.
A research-worthy problem statement is the description of an active challenge (i.e. problem) faced by researchers and/or practitioners that does not have adequate solutions available including the argumentation for its viability based on solid peer-reviewed sources as well as theoretical foundation. The research-worthy problem statement should address all six questions: what, how, where, when, why, and who. On the other hand, a statement of the problem is one or two sentences claim that outlines the problem that the study addresses. The statement of the problem should briefly address the question: What is the problem that the research will address?

2. Analyze the situation

Situation analysis is a marketing term, and involves evaluating the situation and trends in a particular company's market. Situation analysis is often called the "three c's", which refers to the three major elements that must be studied:
• Customers
• Costs
• Competition
The number of "c's" is sometimes extended to four, five, or even six, with "Collaboration", "Company", and "Competitive advantage".

Before developing any given marketing strategy it is important to conduct some form of analysis. This should form an essential part of any business or marketing plan and should be reviewed over time to ensure that it is kept current. Many of my clients often ask me what factors are important when doing this. The following is just a raw marketing 101 introduction to what to take into account when conducting an analysis and provides a checklist if you will of the most important factors to take into account.

The elements worth considering include:
• Product Situation
What is my current product? You may want to break this definition up into parts such as the core product and any secondary or supporting services or products that also make up what you sell. It is important to observe this in terms of its different parts in order to be able to relate this back to core client needs. Feel free to also discuss here which of your client’s needs your product is meeting.
• Competitive situation
Analyze your main competitors – who are they what are they up to – how do they compare – feature/ benefit analysis. What are their competitive advantages?
• Distribution Situation
Review your distribution Situation – how are you getting your product to market? Do you need to go through distributors or other intermediaries?
• Environmental factors
What external and internal environmental factors are there that need to be taken into account. This can include economic or sociological factors that impact on your performance.
• Opportunity and issue analysis
Which requires conduction a SWOT analysis (Strengths, Weaknesses, Opportunity and Threats). Things to write down her are what current opportunities that are available in the market, the main threats that business is facing and may face in the future, the strengths that the business can rely on and any weaknesses that may effect the business performance.
I know for most of you marketing gurus this may be simple knowledge however it is important to realise that sometimes even the smartest forget the core fundamentals.





References:

http://en.wikipedia.org/wiki/Requirements_analysis
http://en.wikipedia.org/wiki/Situation_analysis
http://marketing.about.com/od/marketingplanandstrategy/a/situationanalys.htm
http://en.wikipedia.org/wiki/Problem_statement

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

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.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.


After reading the above scenario, my sympathy is for the side of the Juan that for me he knows more about developing a system to helps the company. Juan applies what he thinks is right in making decisions with regards of developing a system. And I think the manager should take on consideration on the ideas of Juan, because he is more knowledgeable of his field of work than of the manager.


b.What method would you propose they take? Why?

The following are the methods that I propose that they might take:


• System Requirements Analysis

Requirements Analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model.
Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of ‘what’ an application is expected to do.

Given the multiple levels of interaction between users, business processes and devices in global corporations today, there are simultaneous and complex requirements from a single application, from various levels within an organization and outside it as well.
The Software Requirements Analysis Process covers the complex task of eliciting and documenting the requirements of all these users, modeling and analyzing these requirements and documenting them as a basis for system design.
A dedicated and specialized Requirements Analyst is best equipped to handle the job. The Requirements Analysis function may also fall under the scope of Project Manager, Program Manager or Business Analyst, depending on the organizational hierarchy.
Software Requirements Analysis and Documentation Processes are critical to software project success. Requirements Engineering is an emerging field which deals with the systematic handling of requirements.


Studies reveal that inadequate attention to Software Requirements Analysis at the beginning of a project is the most common cause for critically vulnerable projects that often do not deliver even on the basic tasks for which they were designed. There are instances of corporations that have spent huge amounts on software projects where the end application eventually does not perform the tasks it was intended for.
Software companies are now investing time and resources into effective and streamlined Software Requirements Analysis Processes as a prerequisite to successful projects that align with the client’s business goals and meet the project’s requirement specifications.
Steps in the Requirements Analysis Process

I. Fix system boundaries

This initial step helps in identifying how the new application integrates with the business processes, how it fits into the larger picture and what its scope and limitations will be.

II. Identify the customer

In more recent times there has been a focus on identifying who the ‘users’ or ‘customers’ of an application are. Referred to broadly as the ‘stake holders’, these indicate the group or groups of people who will be directly or indirectly impacted by the new application.
By defining in concrete terms who the intended user is, the Requirements Analyst knows in advance where he has to look for answers. The Requirements Elicitation Process should focus on the wish-list of this defined group to arrive at a valid requirements list.

III. Requirements elicitation
Information is gathered from the multiple stakeholders identified. The Requirements Analyst draws out from each of these groups what their requirements from the application are and what they expect the application to accomplish.
Considering the multiple stakeholders involved, the list of requirements gathered in this manner could run into pages. The level of detail of the requirements list is based on the number and size of user groups, the degree of complexity of business processes and the size of the application.
a) Problems faced in Requirements Elicitation
• Ambiguous understanding of processes
• Inconsistency within a single process by multiple users
• Insufficient input from stakeholders
• Conflicting stakeholder interests
• Changes in requirements after project has begun
A Requirements Analyst has to interact closely with multiple work-groups, often with conflicting goals, to arrive at a bona fide requirements list. Strong communication and people skills along with sound programming knowledge are prerequisites for an expert Requirements Analyst.
b) Tools used in Requirements Elicitation
Traditional methods of Requirements Elicitation included stakeholder interviews and focus group studies. Other methods like flowcharting of business processes and the use of existing documentation like user manuals, organizational charts, process models and systems or process specifications, on-site analysis, interviews with end-users, market research and competitor analysis were also used extensively in Requirements Elicitation.
However current research in Software Requirements Analysis Process has thrown up modern tools that are better equipped to handle the complex and multilayered process of Requirements Elicitation. Some of the current Requirements Elicitation tools in use are:
• Prototypes
• Use cases
• Data flow diagrams
• Transition process diagrams
• User interfaces
IV. Requirements Analysis Process
Once all stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.
V. Requirements Specification
Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms. A written requirements document is critical so that its circulation is possible among all stakeholders including the client, user-groups, the development and testing teams. Current requirements engineering practices reveal that a well-designed, clearly documented Requirements Specification is vital and serves as a:
• Base for validating the stated requirements and resolving stakeholder conflicts, if any
• Contract between the client and development team
• Basis for systems design for the development team
• Bench-mark for project managers for planning project development lifecycle and goals
• Source for formulating test plans for QA and testing teams
• Resource for requirements management and requirements tracing
• Basis for evolving requirements over the project life span
Software requirements specification involves scoping the requirements so that it meets the customer’s vision. It is the result of collaboration between the end-user who is often not a technical expert, and a Technical/Systems Analyst, who is likely to approach the situation in technical terms.
The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within.
To overcome this, Requirements Specifications may be documented separately as
• User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user
• System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.
VI. Requirements Management
Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle.




• The System Development Life Cycle

The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases. For any SDLC model that is used, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system will transmit, process, and store.
Applying the risk management process to system development enables organizations to balance requirements for the protection of agency information and assets with the cost of security controls and mitigation strategies throughout the SDLC. Risk management processes identify critical assets and operations, as well as systemic vulnerabilities across the organization. Risks are often shared throughout the organization and are not specific to certain system architectures.
Some of the benefits of integrating security into the system development life cycle include:

Early identification and mitigation of security vulnerabilities and problems with the configuration of systems, resulting in lower costs to implement security controls and mitigation of vulnerabilities;

Awareness of potential engineering challenges caused by mandatory security controls;

Identification of shared security services and reuse of security strategies and tools that will reduce development costs and improve the system’s security posture through the application of proven methods and techniques;

Facilitation of informed executive decision making through the application of a comprehensive risk management process in a timely manner;

Documentation of important security decisions made during the development process to inform management about security considerations during all phases of development;

Improved organization and customer confidence to facilitate adoption and use of systems, and improved confidence in the continued investment in government systems; and

Improved systems interoperability and integration that would be difficult to achieve if security is considered separately at various system levels.
Initiation Phase. During the initiation phase, the organization establishes the need for a system and documents its purpose. Security planning should begin in the initiation phase with the identification of key security roles to be carried out in the development of the system. The information to be processed, transmitted, or stored is evaluated for security requirements, and all stakeholders should have a common understanding of the security considerations. The Information System Security Officer (ISSO) should be identified as well.
Security considerations are key to the early integration of security, and to the assurance that threats, requirements, and potential constraints in functionality and integration are considered. Requirements for the confidentiality, integrity, and availability of information should be assessed at this stage. Federal agencies should apply the provisions of Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. These standards require agencies to categorize their information systems as low-impact, moderate-impact, or high-impact for the security objectives of confidentiality, integrity, and availability and to select appropriate security controls. Any information privacy requirements should be determined as well.
Early planning and awareness will result in savings in costs and staff time through proper risk management planning. In this phase, the organization clearly defines its project goals and high-level information security requirements, as well as the enterprise security system architecture.
Development/Acquisition Phase. During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. A key security activity in this phase is conducting a risk assessment and using the results to supplement the baseline security controls. In addition, the organization should analyze security requirements; perform functional and security testing; prepare initial documents for system certification and accreditation; and design the security architecture.

The risk assessment enables the organization to determine the risk to operations, assets, and individuals resulting from the operation of information systems, and the processing, storage, or transmission of information. After categorizing their systems in accordance with FIPS 199 and 200, federal agencies should meet the minimum security requirements by selecting the appropriate security controls and assurance requirements that are described in NIST SP 800-53, Recommended Security Controls for Federal Information Systems.
Another essential element is the development of security plans, which establish the security requirements for the information system, describe security controls that have been selected, and present the rationale for security categorization, how controls are implemented, and how use of systems can be restricted in high-risk situations. Security plans document the decisions made in the selection of controls, and are approved by authorized officials.
The developmental testing of the technical and security features and functions of the system ensure that they perform as intended, prior to launching the implementation and integration phase.
Implementation Phase. In the implementation phase, the organization configures and enables system security features, tests the functionality of these features, installs or implements the system, and obtains a formal authorization to operate the system. Design reviews and system tests should be performed before placing the system into operation to ensure that it meets all required security specifications. In addition, if new controls are
added to the application or the support system, additional acceptance tests of those new controls must be performed. This approach ensures that new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests should be fully documented, updated as new reviews or tests are performed, and maintained in the organization’s official records.
.
Operations/Maintenance Phase. In this phase, systems and products are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and software components are added or replaced. The organization should continuously monitor performance of the system to ensure that it is consistent with pre-established user and security requirements, and that needed system modifications are incorporated.
Configuration management (CM) and control activities should be conducted to document any proposed or actual changes in the security plan of the system. Information systems are in a constant state of evolution with upgrades to hardware, software, firmware, and possible modifications in the surrounding environment. Documenting information system changes and assessing the potential impact of these changes on the security of a system are essential activities to assure continuous monitoring, and prevent lapses in the system security accreditation.
Disposal Phase. In this phase, plans are developed for discarding system information, hardware, and software and making the transition to a new system. The information, hardware, and software may be moved to another system, archived, discarded, or destroyed. If performed improperly, the disposal phase can result in the unauthorized disclosure of sensitive data. When archiving information, organizations should consider the need for and the methods for future retrieval.
Usually, there is no definitive end to a system. Systems normally evolve or transition to the next generation because of changing requirements or improvements in technology. System security plans should continually evolve with the system. Much of the environmental, management, and operational information for the original system should still be relevant and useful when the organization develops the security plan for the follow-on system.
The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. The removal of information from a storage medium, such as a hard disk or tape, should be done in accordance with the organization’s security requirements.

References:
http://www.unescap.org/stat/meet/rrg3/twsa-module1.pdf
http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf
http://www.archives.gov/records-mgmt/initiatives/sdlc-checklist.pdf
http://en.wikipedia.org/wiki/Requirements_analysis

A. Comment on whose position you sympathize with the most.
Deciding on how the analysis phase is to be conducted, I prefer to be on Peter Pedro’s side. John Juan as it is seen follows the correct procedure on how the analysis phase is to conducted as based on my understanding. I have nothing against him but we have now is the new age therefore, changes must be made every step of the way in order to keep track on the occurrence of the events. John Juan is being noble for he wants to save money as I think so for he wants first to examine whether some aspects of the system can still be used. Years of experience must be the reason why John Juan acted and think that way. But for me, Peter Pedro has the better idea of conducting an analysis phase for he can use the agile methodology wherein, no formal methods are observed. It is the most commonly used methodology for it adapts quickly to the abrupt changes of the system regardless of what will happen on the future or as of the release of the product. With Peter Pedro, sticking to what the old system is a big no for him for he clearly stated that John Juan had repeated the same process and still the desired system never happens, what they can produce is the revised version of the old one. Though I am not saying that the revised version will do no good but still a new system is better than just the modified one. Also, as the manager of a newly built information systems department, it would be for the best if what the department will use is a more innovative version of the old one, I mean the newer the better. John Juan may be a system analyst for ages; still it does not mean that he can provide an improved version of the old system. To sum it all, Peter Pedro has a better view of conducting the analysis phase if you would ask me.

b. What method would you propose they take? Why?

update will be posted soon

This was the scenario:

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

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.

Required:

a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

b. What method would you propose they take?

The question was about the two workers having different views on how the systems analysis phase should be conducted. And then comment on whose position you sympathize with the most. So to start, for me I will go on to Mr. Juan’s point of view in the analysis phase because if the management really wanted a new system, the workflow and all of the processes of the organization will also change. So they will start from the scratch. But still they will base their new system to the goals and objective of the organization. What I like about Mr. Juan’s point of view in the analysis phase is that their business has already been running and had already set the goals and objective of what their business will be. Shall we say we will propose a new system, a really new system and not a modified one, all of the workflow and processes of the business of the organization will be affected and will definitely not the same as before. So that is also a risk that will be taken to account. Before proposing a new system, this is what you need to do in order to have an effective proposal. First is, you must plan and analyze all the necessary information or data that is needed for the new system but you are inclined to the business goals and objective of an organization. I’m not against the idea of Mr. Pedro to propose a new system that is not modified old system, a really new system. He just needs to be sure and work out well all the needed information and data for the new system. Changing an old system to a new system is very risky and hard to do but if it is successful the benefits of the system will be definitely come to use. Planning out a new system but still turning into a modified one is not really bad it is just making things easier, for example the old system is already coming to its full capacity, meaning the memory is coming to its limits then maybe they can modify it to be more efficient in the next 10 years, if not 5 years. When you talk about having a new system you are also taking it to account its life span of service in order for it to be more efficient. Talking about proposing a new system there are risks that is involve so proper planning is needed. But maybe also in addition, if you want to propose a new system you could do these things, it my own idea, first is gather all the needed information, then list all the requirements needed for the new system, then plan it very well and evaluate. Maybe this will help. If things are settled apply those things that are still useful and those things that can be eliminated. But that is only an idea. But generally, with very well planned system is also a good alternative. As relation to God what had said that there is no perfect thing or creature in this world as same as to those systems, just proper development and maintenance in order to have an efficient and well generating system.

b. What method would you propose they take? Why?

So the method that I would propose to them that they will take is the method of a system development process? For me the method depends on what really the management wants in order to make the system. So what are the steps? There are steps in creating a system, so in order for them to develop a system they should follow some protocols in developing a system. So there are steps in developing a system, which is the planning, implementation, testing, documenting, deployment, and maintenance. So these are the steps in system development process. So first things first is what is its definition a software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. The reason why I added the definition is that they can understand what my point is, or shall we say it is an overview in creating or developing a system. So to start, the first step you need to do is to plan; the important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified. So planning is short for SPMP (Software Project Management Plan). SPMP is a technique in which making the planning phase feasible. As you acquired the SPMP that is the time you can proceed to the analysis phase. So part of this is step are the analysis phase in a system development. So the requirements on analysis phase are the SRS or (Software Requirements Specification). Here you are going to identify all the information that is going to be included in your system. An example would be the system features of your system, the functional and non-functional requirements of your system. So if you are done in doing the SRS the next thing you should do is design. So these are some of the things you need to do in order to attain what are the goals that are needed to be accomplished. So if you already finished planning on what are the things you need to do, then you can proceed to the next step which is implementation, testing and documenting. Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal. Then, deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues. The other technique that is crucial in developing a system is that you need to identify your model. There are many examples of models such as waterfall, agile, and extreme programming. But also there are other model that is also needs to be considered. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want. Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Extreme Programming (XP) is the best-known iterative process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature — merging design and code — is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system. The waterfall model shows a process, where developers are to follow these steps in order:

1. Requirements specification (AKA Verification or Analysis)
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation (AKA deployment)
7. Maintenance

After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected.
There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact, this is where the domain of requirements management comes in, which includes change control. The counter argument, by critics to the process, is the significantly increased cost in correcting problems through introduction of iterations. This is also the factor that extends delivery time and makes this process increasingly unpopular even in high risk projects. This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management." Often the supposed stages are part of review between customer and supplier; the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.

Other models

Capability Maturity Model Integration

The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.

ISO 9000

ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards has been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.

ISO 15504

ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

Formal methods

Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, Automated theorem proving, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines. Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine). Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO178B demand formal methods at the highest level of categorization (Level A). Formalization of software development is creeping in, in other places, with the application of Object Constraint Language (and specializations such as Java Modeling Language) and especially with Model-driven architecture allowing execution of designs, if not specifications. Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level.

The Government Accountability Office, in a 2003 report on one of the Federal Aviation Administration’s air traffic control modernization programs, recommends following the agency’s guidance for managing major acquisition systems by

• Establishing, maintaining, and controlling an accurate, valid, and current performance measurement baseline, which would include negotiating all authorized, unpriced work within 3 months;
• Conducting an integrated baseline review of any major contract modifications within 6 months; and
• Preparing a rigorous life-cycle cost estimate, including a risk assessment, in accordance with the Acquisition System Toolset’s guidance and identifying the level of uncertainty inherent in the estimate.

So these are the methods that I would suggest or propose to them.

References:
Google.com
http://en.wikipedia.org/wiki/Software_development_process


visit my blog @ franzcie.blogspot.com

Between the two of them, I think I would side with the idea of Peter Pedro, the manager of the department on which the new information system would be deployed to, not with John Juan the systems professional. Why? Although John Juan’s proposed idea to first examine the system, review key documents and observe workers perform their tasks is good, a systems professional should always first have an understanding with his / her client’s requests and demands so that there would be no unnecessary faults and mistakes at the end.
Having this understanding with the client and the programmer is really important, because the client knows what he or she wants the system to do so that their tasks will be handled efficiently. This is where the requirements engineering phase shall come in. Before the programmer makes the system for a certain office, company or organization, he or she should first determine what the client needs for his or her department. For technical terms, the client with the programmers and developers should first declare what the department’s requirements are.

Here is something to ponder upon:

What is a Requirement?
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.

So that settles it. The requirements play an important role in the making of our system. Without these so-called requirements, the developers won’t have anything to guide them on what to work on with the system of their client/s. The client should specify clearly what he or she wants his or her system to look and work like. If the two parties agree with all the stuff that they have discussed upon, then the possibility of having a nice assignment would get bigger.

Requirements Engineering Products
• The primary outcome of requirements engineering is a requirements specification, a document that acts as:
• An effective contract between user and developer.
• The basis for all subsequent development and verification processes.
• IOutcomes depend on the methodology in use but may include test plans for system and software qualification.

The importance of RE (Requirements )
“On average, 40% of the requirements specified in the Feasibility and Requirements phase of the lifecycle were redefined in the subsequent four lifecycle phases…on average Digital spent 50% more than budgeted.”

 Helps earlier detection of mistakes, which are much more costly to correct if discovered later
 Forces clients to articulate and review requirements
 Enhances communications between participants
 Helps record and refine requirements
 All this is about producing good requirements

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

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.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

-After reading the scenario above, Pedro got my sympathy because he is the client and the one who will be using the system implemented. So we have to consider their needs on what they want to have in their system to be implemented in their company.


b.What method would you propose they take? Why?

In developing a system, there are recommended steps introduced to be follow for more accuracy and for big possibility for the development of the system to be successful. Successful Software Development takes a systematic approach to consistently successful software development. In fact there some key points to successful system development. But of course there no one definite way to develop software systems and introduces a model for a mature software development process that assure success to the development.
One of key points to successful system development is thorough systems analysis and design where understanding the goals and strategies of the business is covered and defining the information requirements that support those goals and strategies is also enclosed. System analysis is a process of understanding in detail what a system should accomplish. While, systems design is a process of specifying in detail how components of an information system should be physically implemented.
In addition, understanding what business requires also plays an important role for successful development of a system. Analysis of the business flow in an organization is a crucial point in developing a system to produce a requirements needed to meet the needs of the clients.

On the conversation stated above between the system professional and manager of the targeted department, there is a conflict on what is the first thing to do. As system professional, the person shows a procedural method to be followed on the analysis phase which is to examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then determine which aspects are working well and which should be preserved. In contrary, the manager suggested to first start with a list of requirements from users. Then, spend some time up-front determining exactly what they want the system to do for their department. Then, systems people can come in and determine what portions to salvage.

The analyst suggested what is good for the development since he has the knowledge and ideas appropriate for the issue. The analyst has a better understanding and ideas of the analysis phase of the development and it must not take for granted for he plays a big important role for the success of the development. But of course, he should take into account the managers request for they are the client and they are the ones who will use the system in the future. The analyst should present and show to the client the consequence and analysis on their way of doing the development and also present the advantage and disadvantage of the process if they follow the managers’ suggestion or their suggested procedure. For them to clarify things and for them to have a good communication and to develop understanding on both side because it is also one of the aspect that is need to be consider in doing a system and for the success of it, understanding .

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.


Both side have a good points on determining where is the best thing that they want to do first, For me as an IT professional i agree on what is the idea of Juan John since their company are already using an electronic system. They must evaluate first their legacy system before they will create a new system, because Pedro can't easily disregard the functionality of the current system it may affect the business transaction of their company. Evaluating their current system also help for a better understanding on what specific problem that they need to be solve for a goodness of the company. I think, starting from analyzing the problem of their current system was a better way to create a new, reliable and a good system. In the other hand pedro also have a point because evaluating the current system will take a lot of time and it will take also a lot of budget which is become a burden to the company in terms of financial.

I recommend the agile methodology refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes. It uses a set of quality management methods, including statistical methods, and creates a special infrastructure of people within the organization ("Black Belts", "Green Belts", etc.) who are experts in these methods. Each Six Sigma project carried out within an organization follows a defined sequence of steps and has quantified targets. These targets can be financial (cost reduction or profit increase) or whatever is critical to the customer of that process (cycle time, safety, delivery, etc.).

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.

Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.

http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Six_Sigma

a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

As a system professional, John Juan’s stand on the first method of acquiring system requirements is mainly through observation so that they could have a thorough understanding of the system. He believes that by observing and understanding the old system, he can get the main requirements needed by the end users who are the workers themselves and not the manager. On his point of view, it is much better to gather requirements on the ‘field of action’ (as I would say) so that he can determine what the significant requirements are and which are not.

As a manager, Peter Pedro’s stand on the first method of acquiring system requirements is giving the system professional the list of requirements and from there make a system out of it. Obviously, he wants a new system that is somehow different from the old one that they are using but still addresses their needs. According to him, their company already encountered a scenario wherein a project was made as a modified version of the old system and not a new one as what has been promised to them. Because of that, he wanted to change the way their company gives system requirements hoping to acquire the ‘new system’ that he really want for their company.

In this scenario, it is clear that both parties have points that they would like to be addressed by the other party. But the question is, who’s position would I sympathize more.

[to be continued]

Consider the following dialogue between a system professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

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.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?



…As the conversation stated above, it just imply a two different people negotiating a certain project but having a doubt to the other. As I see in that conversation it concerns a system professional (john) and the department manager (peter) talking about the project, a new system for the department. In what I have understood, the manager (peter) has a doubt to the system professional (john) about the new system to be made. As what john said that “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”, which means that a professional really needs information and things that they had about the old system because it really matters as the analyst needs to analyze why the department wanted a new system.

A. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
Obviously I sympathize the most to the system professional (john juan). As an IT student I agree to his first idea that the first thing they need to do is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks and then determine which aspects are working well and which should be preserved. As IT student it is the most proper way of what are the first thing you need to do before creating a new system. John Juan also analyzes why the department changing their system. With that question of course the first thing you should do is to know what the functions, features and processes are of their old system has as the reason of why they are changing it. Let just say that the department wanted to innovate their old system and improve more functionalities. Of course in order to know what the those constrains you should first examine the old system and gather information of it so that you can have a good and satisfactory output of the system. continue.......