要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
モナドのすべて Haskell におけるモナドプログラミングの理論と実践に関する包括的ガイド
モナドのすべて Haskell におけるモナドプログラミングの理論と実践に関する包括的ガイド Version 1.1.0 このチュートリアルは、モナドの概念とその関数プログラミングにおける応用に ついて、初中級の Haskell プログラマにわかりやすく、利用価値があるような 解説をすることを旨としています。読者は Haskell になれていることを前提と しますが、モナドに関する経験は要求していません。このチュートリアルは、多 くの題材をカバーしています。後半のセクションでは、前半の題材をよく理解し ていることを前提とします。順をおって、モナドプログラミングを例示するため のサンプルコードがたくさん用意されています。一読で、すべての題材を吸収し ようというのはお勧めできません。 このチュートリアルは 3 つの部分で構成されています。最初の部分は、 関数プログラミングにおけるモナドの基本的
翔ソフトウェア (Sho's) - XP (エクストリーム プログラミング) - ソフトウェア職人の称号
ソフトウェア職人の称号 2002/08/07 アジャイルな技術者とそうでない技術者 最近はデフレの影響か (*1)，アジャイル (Agile: アジャルとも発音する) なソフトウェア開発手法というのが日本でも随分と話題に上がるようになってきたようである． XP (エクストリーム・プログラミング) を筆頭に，Scrum や AM (Agile Modeling) 等… うちの会社でも不況の影響から余りお金が使えなくなってきたこともあり (*2)，近頃はこのアジャイルな開発方法というのを社内に広めようと目論んでいる． で，最近感じていることだが，技術者の中にもこの「アジャイルなやり方」に拒否反応なしで積極的になじんでいく人と，抵抗を示す人とがいる (愚痴モード: 「銀の弾丸」でないのは確かだろうが，「対案の無い否定的意見」では誰も幸せになれないので困ってしまう)． どうやら比較的アジャイルな技
RSSによるサイト情報の要約と公開
メタデータ/RDFの応用として利用されているXMLフォーマットの代表として、RSS (RDF Site Summary) があげられます。共通の書式でドキュメントの見出し、要約などのリストを提供することで、サイトの更新情報などを効率的に公開できます。 RSS 1.0の要素と構文 channel要素 item要素 シンプルなRSSの全体 RSS 1.0全要素のツリー RDFとして見た場合のRSS RSSのRDFモデル RDFモデルの補足説明 RSSの拡張/応用とモジュール Dublin Coreモジュール Syndicationモジュール Contentモジュール そのほかのモジュール RSSとセキュリティ RSSの実際の利用 RSSの歴史〔補足〕 参照文献 ※RDFの体系的な解説『RDF/OWL入門』を上梓しました。 RSS 1.0の要素と構文 RSS (RDF Site Summary)
＠IT：初めてのプロジェクトリーダー（4）開発中、リーダーは何をしている？
1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン（イベント）も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。 納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表（ガントチャート）ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。 どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必
機能テストとは何か? - たまゆら雑記
つい最近、機能テストって何だろうと話をしていました。 この機能テストという言葉は非常にやっかいな言葉で、コミュニケーションを取るのが難しい用語の一つです。 難しいということを知っていて、それなりに注意を払って話をしてみても伝わらないものは、なかなか伝わらないものです。 多くの書籍でも同様で、みな 好きなことを喋っている としか思えません。えっ、そう思わないって！ では少しばかりご覧ください。機能テストにまつわるさまざまな記述を。 「ソフトウェア・テストの技法」(Myers) p.118より引用 機能テストは、プログラムと外部仕様との相違点を発見する過程である。外部仕様は、外部世界（たとえばユーザ）からみたプログラムの行動について正確に記述することである。 「ソフトウェアテスト技法」(Beizer) p.9、p21、p422より引用 機能テストでは、プログラムやシステムを１個のブラックボック
プラトン編－イデア論とクラス／インスタンス
第9回（分析手法のキホン：「分解と分類」）は認識対象を理解するために行う分析の2つの技法「分類と分解」について考えてみました。日常生活でも、あるいはシステム開発で行うモデリング作業にも、この類似した2つの概念が表れ混乱することがありますね。どのように違うのでしょうか？ 分類は“is-a”関係と呼ばれ、UMLでは汎化関係で表現できる。分解は“has-a”関係と呼ばれ、UMLでは集約関係で表現できる。 分解による方法は、複雑な対象を単純で理解しやすい小さな部分に細分化するという発想ですが、全体としてこそ保有されるべき性質が分解により失われ、分解された部分の性質の総和が全体にならないという問題があります。「木を見て森を見ず」になります。分類による方法は、全体としての基本的な性質を消さないようにしつつその性質を細部にまで追求する方法であるということができます。 世界の森羅万象について、その本質は何
jkondoの日記 - あしかのあしあと
今日で3月も終わり。明日からはてなのスタッフも増えて、事務所も拡張ということで、また一つ区切りだなあーと感じます。 はてなでは、色々な機能追加や変更など、開発のタスクをタスクカードに書いて進行管理をしています。タスクカードといってもただのコピー用紙の裏紙で、進行管理といっても、ただの段ボール箱を区切って紙切れを入れているだけです。 その名は「あしか」。 そんな進行管理ですが、いい区切りだと思ってこれまでに実装を行ったタスクを見てみると、随分とたまりました。（写真の左奥の仕切りが「終わった」の箱です） ちなみに、区切りは4つあって 終わった すぐやる そのうちやる ペンディング に分かれています。ペンディングに入ったアイデアやプランは、なかなか手をつけることができませんが、大きなテーマや楽しいアイデアもいっぱいです。 人も少しずつ増えて、さらにスピードを上げてやるべきことをどんどんできるよう
＠IT：Flashベースのリッチクライアントを体験 第3回
Flashベースのリッチクライアントを体験（3） 1/2 Flex Builderで新規アプリの開発に着手しよう 電通国際情報サービス 比嘉 康雄 2005/6/10 「Macromedia Flex」（以下、Flex）は、J2EEアプリケーション・サーバ上で動作するプレゼンテーション・サーバであり、XMLのタグベースでFlashによるユーザー・インターフェイスを定義します。マクロメディア社から提供されているHTMLオーサリングツール「Macromedia Dreamweaver」をベースとした開発ツールが用意されており、それが今回紹介する「Macromedia Flex Builder」（以下、Flex Builder）になります。WYSIWYGにデザインすることができるため、非常に快適に開発を進められます。 前回の記事「Flex開発環境「Flex Builder」のセットアップ」で、F
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
